[Pgi-wg] Comments from Marvin Theimer June 5, 2006 (should be in archieve)

[Andrew Grimshaw]

have the following questions about BES and the various discussions that have
recently occurred (including the ESI integration):

*        Extensibility:

*        Given that BES has bought into the notion of an extensible activity
state diagram, it needs to also normatively define how clients can learn of
the extensions that a given BES service supports.  Is that something that
will be added to the BES specification?  Or will the specification point to
some other place where notions of extensibility are defined more
generically?  (Personally, I'd vote for the former approach.)

*        Is the "base case" for BES now fig.2, which shows states of {new,
pending, running, canceled, failed, finished}?

*        Previously included states, such as Execution-Pending, will
presumably be defined in suitable extension profiles?

*        Assuming that data staging and suspension are now extensions to the
base BES spec, will they be defined as such in an appendix of the spec, or
as a separate extension profile?

*        The original BES spec describes a fairly sophisticated data staging
design that supports parallelism.  Is there any interest in defining a
second, simpler data staging extension that avoids the complexity of the
parallelism support?

*        Will the suspension extension be the simple one that is currently
presented in sec. 4 as an example?  Or do people feel that a more
complicated version, such as the ESI one is necessary/important?  Can/should
we define both?

*        Given that suspension is no longer in the base design, presumably
the createInSuspendedState parameter to CreateActivityFromJSDL should
disappear?

*        RequestActivityStateChange: I believe this operation will pose
challenges in an extensible design.  The current design is imperative by
nature: it specifies an explicit state to move an activity to.  However, a
client who does not know of all the extensions that a BES service implements
may not know how to pick the appropriate state to transition to.  It seems
better to introduce a more declarative approach in which clients specify
"actions" they wish to occur, such as 'CancelActivity'.  This approach would
allow the BES service to make the appropriate state transition in response
to a desired action requested by a client.

 

 

**** Comment by Andrew on April 8, 2009

In Genesis II we have implemented sub-states for staging (in, out) and
suspend/resume. I'm thinking that we should profile the substates, and add
change state.

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090408/92acaf15/attachment.html