[ogsa-bes-wg] V21 of the BES draft

Tue Aug 15 20:57:37 CDT 2006

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:
>
><bes-factory:OverallStatus
>         xmlns:bes-factory="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/>
>                 </vcgr:Staging-In>
>         </bes-factory:Running>
>
></bes-factory:OverallStatus>

_______________________________________________________________
    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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060815/adbe0f18/attachment.htm 