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.