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 <pstrong@ebay.com> To: <ogsa-bes-wg@ogf.org>, <ogsa-wg@ogf.org> 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
