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
