The ESI document is presented as a 'new' specification and makes little reference to the current BES drafts. It is therefore difficult to explicitly identify the differences, between this document and the BES specification. The following appear to be the significant differences (ignoring rendering related issues) that appear from reading the document and discussions with Dave Snelling during the EMS session at the OGSA F2F a few weeks ago. I'd suggest the priority of the telecon this week would be to capture any additional issues (before getting bogged down in details) as many of these issues have already been discussed previously but not included in the specification due to a lack of group consensus on these issues. * Unique Identifier on submission This has discussed several times in the past and has appeared and disappeared from the BES specification - currently out - as BES probably thought it could go into JSDL. The JSDL gurus at the F2F felt that this did not belong in the JSDL document itself (their argument - it has nothing to do with describing the job) but sat within the message body of the create activity (or equivalent) operation. There was some discussion at the F2F about the failure semantics of the lower-level layers (beneath the webs ervice) that should be included here. [Expansion of the WS-Addressing comment on ESI page 3 would be welcome.] * State Model The main difference (at first glance) is a distinct Hold state for each primary state - although BES records the proceeding state so the BES generic Hold is qualified with where it came from. Dave Snelling stated that the state model was still under discussion so no further comment will be made here. However, it appears to be clear that different state models may be associated with different activities - and in many cases may be simpler that either the BES or ESI document. Perhaps linking the state model to the JSDL application type (e.g. POSIX) may be a way forward? This would allow (say) a WebServiceApplication type in the JSDL document to have a very simple model (running/not running). * Activity Interface Once the job has started in ESI it presents an interface that can be used to control the job. BES does not require or exclude the presence of such an interface, as activity specific control is done through the interface. Indeed, there is a probably a case to be made for 'any' interface to be described here - the job control interface described in the ESI document, and activity specific interfaces. There was some discussion in BES-WG of the POSIX JSDL job type being linked to a POSIX Activity Interface for control purposes. This generic capability would seem worth pursuing. * Information Model Again, there has been much discussion with BES-WG and the OGSA-WG on the 'right' way to describe the BES container and the activities within it - picking up on CIM, GLUE and JSDL work. These segments of the ESI document should be compared to the work done in this area to date. If the inclusion of supported applications/libraries is important this should probably be modeled here. * Notification I don't think there is any particular issue that it should be possible for a something to subscribe to state changes. Mandating WS-Notification mechanisms with the WS-RF rendering is obviously one route. As is WS-Eventing in other renderings. BES does not mandate one mechanism over another. * Notification on Submit BES supports something approaching this by submitting into a suspended state at which point notification is set up. There is a gap here between BES and ESI functionality. These are the major items from my scan of the documents and my notes from the F2F. There may be others... please add to them. -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK