Hi BES folx, The SAGA Core Specification is getting closer to completion. One of the elements we wanted to use from the OGSA-BES specification is its state model. We had some discussion with Marvin Theimer and Chris Smith at GGF17, and back then it looked like the BES and SAGA state model would converge very nicely. What is the current state of the state model (hope you appreciate the clever play of words)? Is it expected to undergo major changes before the OGSA-BES spec goes into the document pipeline? In the doc version as sent by Morgan I could not immediately find any information about allowed/forbidden state transitions. Is there a complete state diagram available? Also, I missed the Suspended state, which was in discussion earlier - is that gone? Is that supposed to be part of the state detail in the Running state? If yes, the SAGA state diagram would need to differ from the BES state diagram: in SAGA, Suspended is supposed to be a top level state. Sorry if these issues should be clear from the doc, or from the discussions on this list - I was not able to follow the BES activities as closely as would have liked to... For what its worth, I attach the current SAGA state diagram. IFAICS, exchanging SAGA::New with BES::Pending and SAGA::Unknown with BES::New would yield the current BES state diagram - apart from SAGA::Suspend that is. Thanks, Andre. Quoting [Mark Morgan] (Aug 15 2006):

Fellow BES'ers,

I have uploaded to GridForge (and attached to this email for your convenience) my revamped version of the BES specification as agreed to during last week's telecon. The great majority of changes reflect resolutions that we reached on that telecon and include a re-work of the state model (both in text and xml form) as well as a rework of the attributes or info model (again, in text and XML form). It is my belief that the document now constitutes a consistent story from English description through XSD and WSDL though by no means should the document be considered fully proofed or ready for ppublishing. The following details apply:

The version of the document that I uploaded is based originally on that received from Mr. Ian Foster and so should include many of his changes. As per the BES telecon discussion, some of the material in that document has been moved to an appendix. In particular, the discussion on JSDL extensions is now an appendix (in fact, I simply cut-and-paste that chapter into the appendix so no editing has been done there and probably should be before we go public).

Also, the specification had been split into three separate port types; management, factory, and activity. As per our discussions, activity is out of scope for BES but quite reasonable as an appendix. I therefor removed this port type from the document proper. However, I didn't feel like I had the time nor the vested interest in that port type necessary to do it justice. It therefor has not been re-added into an appendix and if the group feels like it has a place there, some work needs to be done to re-insert it.

In Ian's original draft, each of the separate port types had it's own attributes/properties. However, as per resolutions on last week's telecon, this no longer fit the model we had agreed upon. I have therefor moved all such attributes into the management port type (which seems reasonable as one could construe info model as a management function).

Finally, just to be clear on how I handled the state model (as I think this was one of our key features), I have defined a new data type called OverallStatusType which contains exactly one of bes-factory:New, bes-factory:Pending, bes-factory:Running, bes-factory:Cancelled, bes-factory:Failed, and bes-factory:Finished as a child element. Each of these elements in turn has an xsd:any inside which can be used for arbitrary specialization or sub-stating. For example, suppose I wished to reflect that I was in the Mark Morgan Blocked sub-state of the Uva VCGR Staging-In sub-state of the spec. defined Running state. My XML for that would look like:

http://schemas.ggf.org/bes/2006/08/bes-factory" xmlns:vcgr="http://vcgr.cs.virginia.edu/bes/2006/08/states" xmlns:morgan="http://mark-morgan.org/bes/2006/08/states">

bes-factory:Running vcgr:Staging-In morgan:Blocked/

-- "So much time, so little to do..." -- Garfield

Mark: You have done an outstanding job. This is looking really very nice, IMHO. I'll resist the temptation to take the pen for a quick edit, but instead just make a few comments: 1) I disagree with moving the BES-Activity document to an appendix: that feels like a funny half-way house. If we don't want it in the main body of this specification, then I propose we move it into a separate spec. Either resolution is fine with me. 2) I also disagree with moving the JSDL extension discussion to an appendix, for the same reason. In this case, I want to argue for restoring the material (probably just the first two extensions) in the main body. I can work on more detailed text if desired. 3) Section 5.1 is quite verbose: could we not replace it with a table? If that is not preferred, then we should add a table summarizing the attributes. (In both cases, the table shculd ontain the data we had previously showing number of occurences--that is useful information.) 4) Someone had commented that Start/StopAcceptingNewActivities should allow for a "notauthorized" fault. Was it decided that this was not required? 5) The description of the response from TerminateActivities ["The Cancelled element is a boolean value indicating whether the BES container successfully (true) cancelled the activity or not (false)."] seems inconsistent with the earlier text saying that the operation only passes the request to the activity--it does not confirm that it succeeded in cancelling it. 6) In F.3.2, G.1.2, and elsewhere, I propose that the example ActivityReferences simply be shown as WS-Addresses, leaving open the question of what reference parameters may or may not be included in those WS-Addresses. This representation is more consistent with our statement in Section 3 that we do not require WS-Naming syntax, and also give us one less thing to explain. 7) I thought that the text in Appendix A could be clearer, and also would be more useful in the introduction. I propose that we remove Appendix A, and place the following text at the end of the Introduction, which also provides a useful summary of the Appendices. We define in Appendices A-D normative XSD and WSDL for BES-Management and BES-Factory, respectively, and in Appendices E and F non-normative examples for the two interfaces. Recall that the OGF OGSA WG has defined the notion of a Base Profile: a specification that places certain constraints on how resource modeling specifications such as the WSRF or WS-Transfer families should be used in any OGSA-compliant specification. At the time of writing, only an OGSA WSRF Base Profile [OGSA WSRF BP] has been defined, but others will presumably be produced in the future. We have sought to define a BES specification that while not, in itself, compliant with any OGSA Base Profile, can be composed with appropriate other port-types to produce a BES that is compliant with any specific OGSA Base Profile. To illustrate how this composition can be achieved, we explain in the (non-normative) Appendix H how an implementor can construct a BES that is compliant with the OGSA WSRF Base Profile. 8) I also propose the following alternative text for Appendix I (Appendix H if we remove Appendix I): We explained in the Introduction how the BES specification is designed to enable the creation of BESs that are compliant with OGSA Base Profiles via the composition of BES port-types with other appropiate port-types. To illustrate how this can be done, we explain how an implementor would create a BES that is compliant with the OGSA WSRF Base Profile. This material is not intended to be normative. 1) A BES that is to be compliant with the OGSA WSRF Base Profile must implement, in addition to the BES-Management and BES-Factory port-types, the WS-ResourceProperties, WS-ResourceLifetime, and WS-BaseNotification port-types, in a manner compliant with the OGSA WSRF Base Profile. 2) Implementers MUST also ensure that all attributes given in the description of the attributes document appear as exactly named WS-ResourceProperties. Exactly named here implies that each resource property must have the QName {http://schemas.ggf.org/bes/2006/08/bes-management}attr-name where attr-name is the name of the attribute used inside the attributes document types (e.g., TotalNumberOfActivities, CommonName, etc.). Ian. At 05:26 PM 8/15/2006 -0400, Mark Morgan wrote:

Fellow BES'ers,

I have uploaded to GridForge (and attached to this email for your convenience) my revamped version of the BES specification as agreed to during last week's telecon. The great majority of changes reflect resolutions that we reached on that telecon and include a re-work of the state model (both in text and xml form) as well as a rework of the attributes or info model (again, in text and XML form). It is my belief that the document now constitutes a consistent story from English description through XSD and WSDL though by no means should the document be considered fully proofed or ready for ppublishing. The following details apply:

The version of the document that I uploaded is based originally on that received from Mr. Ian Foster and so should include many of his changes. As per the BES telecon discussion, some of the material in that document has been moved to an appendix. In particular, the discussion on JSDL extensions is now an appendix (in fact, I simply cut-and-paste that chapter into the appendix so no editing has been done there and probably should be before we go public).

Also, the specification had been split into three separate port types; management, factory, and activity. As per our discussions, activity is out of scope for BES but quite reasonable as an appendix. I therefor removed this port type from the document proper. However, I didn't feel like I had the time nor the vested interest in that port type necessary to do it justice. It therefor has not been re-added into an appendix and if the group feels like it has a place there, some work needs to be done to re-insert it.

In Ian's original draft, each of the separate port types had it's own attributes/properties. However, as per resolutions on last week's telecon, this no longer fit the model we had agreed upon. I have therefor moved all such attributes into the management port type (which seems reasonable as one could construe info model as a management function).

Finally, just to be clear on how I handled the state model (as I think this was one of our key features), I have defined a new data type called OverallStatusType which contains exactly one of bes-factory:New, bes-factory:Pending, bes-factory:Running, bes-factory:Cancelled, bes-factory:Failed, and bes-factory:Finished as a child element. Each of these elements in turn has an xsd:any inside which can be used for arbitrary specialization or sub-stating. For example, suppose I wished to reflect that I was in the Mark Morgan Blocked sub-state of the Uva VCGR Staging-In sub-state of the spec. defined Running state. My XML for that would look like:

http://schemas.ggf.org/bes/2006/08/bes-factory" xmlns:vcgr="http://vcgr.cs.virginia.edu/bes/2006/08/states" xmlns:morgan="http://mark-morgan.org/bes/2006/08/states">

bes-factory:Running vcgr:Staging-In morgan:Blocked/

_______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org.