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

[Peter G. Lane]

This thing's really shaping up! Kudos to everybody!

A very minor nitpick: I would prefer the official BES-Management NS prefix to be "bes-mgmt" instead 
of "bes-man". The "mgmt" abbreviation for "management" is quite common, whereas this is the first 
time I've seen "man" used to abbreviate it.

Typo: first paragraph of "JSDL 1.0 Overview" has "state out" when it should be "stage out".

In the third bullet under "Naming Activities: Endpoint Refereces" (and consequently in section 
1.1.7), Should we in fact be using the namespaces from the WS-Addressing and WS-Naming specs for the 
definitions of EndpointReferenceType instead of the BES-centric namespaces created solely for this 
spec to identify the same things? I feel like the namespaces here are unnecessarily arbitrary.

Typo: second paragraph of section 6.1. should have "may contain 0" instead of "may contains 0".

Could we change "My Organization's Big Iron" in secion 1.1.2 to "My Organization's Big Iron 
Machine"? The current text sounds a little funny. It'll also jive a little better with the LongName 
example.

The descriptions for sections 1.1.15 and 1.1.16 seem to imply that the associated operations are 
merely suggestions for ceasing or resuming job processing as opposed to operations that would, say, 
block until the job acceptance state of the BES is changed. Was this intentional? If not, I feel 
like the base semantics should be made more clear.

Typo: the description for section 1.1.17 should end with "attributes.", not "attribute.".

The operation definition sections should either have real type names (i.e. jsdl:JobDefinition 
instead of JSDLDocument) or remove the pseudo type names from the arguments. I would opt for the 
latter since the WSDL defines all of this anyway. It's additionally confusing that the use of pseudo 
type names is inconsistent.

I don't understand what ContainedResourceAttributes is. Is this an aggregation of all the 
activities' resource attributes? If so, why isn't obtaining this data done through an operation like 
GetActivitiesStatus or GetJSDLDocuments? Aggregation of activity attributes is problematic from an 
implementation point of view. It forces the implementation to compromise between freshness of the 
data and performance of the services. Granted one could implement a dynamic attribute that gets 
populated on demand, but this seems inconsistent with the way the other aggregated data is handled.

Lastly, I disagree with the decision to move all the attributes into the BES-Management schema. This 
leaves me unable to, for example, only support the BES-Factory interface since all the useful 
information is missing from the port type that defines the essential operations. My understanding 
was that supporting both port types was optional, but doing it this way essentially contradicts that 
statement. I'll put it another way: this information is not "management" data in terms of managing 
the BES service itself (what the BES-Management port type was intended for). The attributes relate 
to management of the underlying compute resources and the activities that are using them. That's 
exactly what the factory interface is for. So I don't particularly care if the attributes all remain 
in one schema or not, but I feel strongly that the schema they are in should be the factory schema.

Peter

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3804 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060815/c91c23ad/attachment.bin