Hi all,
Paul Strong, you may remember him as GGF18 keynote speaker,
asks me to forward his comments on BES spec to OGSA-BES-WG
list.
Thanks,
--
Hiro Kishimoto
-------- Original Message --------
Subject: [ogsa-wg] BES Comments
Date: Tue, 21 Nov 2006 11:18:25 -0700
From: Strong, Paul
To: ,
All,
I have been attempting to catch up on BES and was reading the v1.0
document. I have some questions and comments. Please note that I have
no context from meetings or discussions about BES so please forgive my
ignorance, I may be missing important context or details :o)
i) Why are there 2 client focused interfaces (3
interfaces in total)? It is very natural for there to be 2 interfaces
to a service/component, one focused on delivering client functionality
and one for manageability. It is also natural to minimize the number of
interfaces and the calls across them so as to aid maintainability. It
would appear to me that the difference between the two BES client
interfaces is that one allows activities to be created and for
collections of activities to be monitored and managed. The other is
focused on individual activities, but includes very similar
functionality. There seems to be a lot of commonality. What are the
reasons for them not being combined? Indeed as I read further I note
that BES-Activity exposes no operations, so perhaps this interface is
being deprecated and the document is in the process of being edited?
ii) Why does the state model not end in one terminated
state? Are there any real differences between the 3 enumerated end
states other than how the activity ended up in the state?
iii) Also it seems somewhat counter intuitive that if
one is going to have three termination states, one should end up in the
one state which reflects both success and failure (Finished) and a
separate one for failures that prevent the activity from exiting in a
controlled fashion. It seems like the transitions to the terminated
state should be something like -
a. Completed Successfully
b. Failed
c. Cancelled
iv) Is there any notion of a retry, given that the
state machine captures failure? Or perhaps rescheduling? For example
one could imagine additional useful transitions -
a. Pending to Pending - i.e. rescheduling
b. Running to Pending - i.e. failed/retrying
Having these in the base profile or basic model would enable greater
flexibility in implementing future profiles where one could request that
the BES container implement retries or allow rescheduling. Or are you
categorically stating that users will never be able to reschedule or
request automatic retries. Again if this is the case, it should
probably be explicitly stated. I would actually urge you to make the
base specification as broad as possible in terms of the acceptable state
changes at this level to avoid unnecessarily constraining yourself down
the line. I think this is especially important given what is stated in
4.2.
v) Labeling of the state transitions would be most
helpful, together with the adoption of standard UML statechart
representation. Included is a state transition diagram which includes a
few additional transitions which may, or may not be helpful/appropriate.
:o)
vi) 4.2 - State Specialization really seems to be
indicating that this specification makes no assumptions with respect to
sub-states that may be incorporated within an implementation but that
such sub-states are acceptable as long as they do not introduce new
state transitions between the standard, specified states. It would be
very helpful to simply state this before all of the examples.
vii) Do you expect to extend the BES model to activities
that are not binaries running on operating systems?
Regards
Paul
--
ogsa-wg mailing list
ogsa-wg@ogf.org
http://www.ogf.org/mailman/listinfo/ogsa-wg
