[ogsa-bes-wg] V21 of the BES draft
Mark Morgan
mmm2a at virginia.edu
Wed Aug 16 08:52:06 CDT 2006
> Let me say again that Mark has done an outstanding job.
Thank you
> A Q: should I add the items below as trackers?
That would probably be best. I suspect that some of these issues need to be
discussed in group.
Thanks,
Mark
>
> Ian.
>
>
>
> Delivered-To: grdfm-ogsa-bes-wg-outgoing at mailbouncer.mcs.anl.gov
> X-Original-To: grdfm-ogsa-bes-wg at mailbouncer.mcs.anl.gov
> Delivered-To: grdfm-ogsa-bes-wg at mailbouncer.mcs.anl.gov
> X-Sender: itf at pop.mcs.anl.gov
> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
> Date: Tue, 15 Aug 2006 20:57:37 -0500
> To: "Mark Morgan" <mmm2a at virginia.edu>, <ogsa-bes-wg at ggf.org>
> From: Ian Foster <foster at mcs.anl.gov>
> Subject: Re: [ogsa-bes-wg] V21 of the BES draft
> Sender: owner-ogsa-bes-wg at ggf.org
>
> 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
> <http://www.ci.uchicago.edu/> .
> Globus Alliance: www.globus.org <http://www.globus.org/> .
>
>
> _______________________________________________________________
> 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
> <http://www.ci.uchicago.edu/> .
> Globus Alliance: www.globus.org <http://www.globus.org/> .
>
>
>
More information about the ogsa-bes-wg
mailing list