[OGSA-BES-WG] BES Last Call

[Andreas Savva]

If I may, I have an additional comment on the following point:

> Naming Activities: Endpoint References
>  >   A BES implementation MUST always present an XML anyURI to
> clients and this
>  >   single anyURI MUST be one of a well-defined set of URIs that
> represent the
>  >   types of endpoints that the BES implementation deals with. Two
> URIs are
>  >   defined:
>  >   http://schemas.ggf.org/bes/2006/08/bes/naming/BasicWSAddressing
>  >   http://schemas.ggf.org/bes/2006/08/bes/naming/WS-Naminghttp://
> schemas.ggf.org/bes/2006/08/bes/naming/WS-Naming
>
> I think this is referring to the NamingProfile BES-Factory attribute,
> but it is quite unclear from the context. Is it strictly required to
> have only those
> two URIs hard-coded and not have extensibility here?

At GGF18 during a BES session and when reviewing BES draft 28 (I think)
 we agreed to remove these BES WS-Naming URIs because WS-Naming was
defining a bunch of them already. There is no reason to have duplicate
definitions.

Also because WS-Naming defines separate claim URIs for each of its
sub-profiles (and because an implementation is free to claim support for
any set of those sub-profiles) we agreed that a BES implementation may
present "one or more" naming URIs to indicate which set of naming
conventions it supports.

(Hopefully Mark and Andrew should remember that discussion.)
Andreas


Joseph Bester wrote:
> Sorry for coming in so late to this discussion. As I wasn't too  
> involved in the earlier drafts, I'm not sure how much of this has  
> been covered already. Below are my questions and comments on the  
> latest draft. Each concern is separated by a -- and tries to refer to  
> the nearest heading or subheading title in the document.
> 
> joe
> 
> Naming Activities: Endpoint References
>  >   A BES implementation MUST always present an XML anyURI to  
> clients and this
>  >   single anyURI MUST be one of a well-defined set of URIs that  
> represent the
>  >   types of endpoints that the BES implementation deals with. Two  
> URIs are
>  >   defined:
>  >   http://schemas.ggf.org/bes/2006/08/bes/naming/BasicWSAddressing
>  >   http://schemas.ggf.org/bes/2006/08/bes/naming/WS-Naminghttp:// 
> schemas.ggf.org/bes/2006/08/bes/naming/WS-Naming
> 
> I think this is referring to the NamingProfile BES-Factory attribute,  
> but it is quite unclear from the context. Is it strictly required to  
> have only those
> two URIs hard-coded and not have extensibility here?
> 
> --
> 
> Defining Valid Specializations
> 
>  > BESs MUST not implement such specialization profiles. More  
> specifically, any
>  > specialization profile that a BES implements MUST obey the  
> following rules
>  > regarding sub-state definitions and allowed state transitions:
>  >
>  > 1. A specialization can introduce sub-states only by replacing a  
> state in the
>  > state model that it is specializing (which itself may be a  
> specialization of
>  > some other state model) with a graph of sub-states and state  
> transitions
>  > among those sub-states.
>  > 2. A state transition from any sub-state in the specialization to  
> another
>  > state, S, in the unspecialized state model may only occur if a  
> corresponding
>  > state transition already existed in the unspecialized state model  
> from the
>  > state that has been replaced, R, to that state S.
> 
> The wording of #1 is a little bit amiguous: it might be interpreted  
> as stating
> that specialized states must only have transitions within the new  
> substate
> graph. It might also clarify things to explicitly allow transitions to
> substates of S in #2.
> 
> --
> 
> Composition of Specializations [1] and Specialized Fault Responses [2]
> [1]
>  > This case raises the question of what to tell a client about their  
> request,
>  > and when. The client may wish to receive a response to its request
>  > immediately, telling it that the request will eventually be  
> applied once the
>  > relevant activity has progressed to a suitable sub-state.  
> Alternatively, the
>  > client may wish to receive a response to its request only when the  
> requested
>  > change has actually occurred. To support both response cases  
> requires that
>  > clients can specify in a request whether they wish to receive an  
> immediate
>  > response back or whether they wish to only receive a response once  
> the
>  > request has actually been acted upon. In the former case a client  
> must be
>  > prepared to receive back a fault response indicating that their  
> request will
>  > eventually be applied.
> [2]
>  > The OperationWillBeAppliedEventuallyFault is used by the BES to  
> indicate to
>  > the client that the requested state operation is allowed, but that  
> the
>  > operation can not be applied immediately given the current  
> Activity state. By
>  > throwing this fault, the BES indicates to the client that it will  
> apply the
>  > requested operation when the Activity state allows. For example,  
> an Activity
>  > in Running:Migrating sub-state can not be put into  
> Running:Suspended, until
>  > the Activity has completed the migration operation, and is back in  
> the
>  > Running:On-resource sub-state.
> 
> I'm not terribly happy with this particular fault. It seems like this  
> is a
> gap in the state transition diagram for the substates---the
> server is moving the job into some intermediate state (between  
> migrating and
> suspended in this example) rather than to the desired state. Since  
> the server
> intends to move to the suspended state, it seems like a poor  
> candidate for a
> fault. Also, this fault isn't actually used in the description of the  
> only
> client-initialized state transition (TerminateActivities)
> 
> --
> 
> Representing sub-states
> 
> 
> There isn't a clear XML example of how a union state would look. The  
> reference to section 4.3
> is wrong---that part is about specialized fault responses.
> 
> --
> 
> BES-Management Port-type (Attributes and Operations)
> 
> Port-type vs Port-Type in subsequent sections. No Attributes are  
> described in
> this section despite the heading.
> 
> --
> 
> StopAcceptingNewActivities, StartAcceptingNewActivities
>  > Output(s)
>  > - None. The response message will be sent once the BES has stopped
>  >   accepting new activity creation requests.
>  > - None. The response message will be sent once the BES has started  
> accepting
>  >   new activity creation requests
> 
> 
> Is it necessary to allow the service to block the client for an  
> indeterminate time? Other state
> transitions described in the doc allow for a BES implementation to  
> intend to make the state change
> without guaranteeing that it is done before the reply is made.
> 
> --
> 
> BES-Factory attributes
> 
> General note: not all attributes in the table are listed in the schema
> (I noticed TotalNumberOfActivities and  
> TotalNumberofContainedResources were
> missing)
> 
>  > ContainedResource anyType
> 
> Is it intended to use an anyType holding a  
> BasicResourceAttributesDocument
> or FactoryResourceAttributesDocument or is it intended to have the
> ContainedResource element be of type  
> BasicResourceAttributesDocumentType or
> FactoryResourceAttributesDocumentType?
> 
> To clarify what I mean:
> 
> <!-- holding a FactoryResourceAttributesDocumentType -->
> <ContainedResource>
>      <FactoryResourceAttributesDocumentType>
>          <IsAcceptingNewActivities>true</IsAcceptingNewActivities>
>      </FactoryResourceAttributesDocumentType>
> </ContainedResource>
> 
> or
> 
> <!-- of type FactoryResourceAttributesDocumentType -->
> <ContainedResource xsi:type="FactoryResourceAttributesDocumentType">
>      <IsAcceptingNewActivities>true</IsAcceptingNewActivities>
> </ContainedResource>
> 
> --
> 
> BES-Factory attributes
>  > LocalResourceManagerType URI
> Should there be a specific URI defined for the case where the BES  
> acts as a
> facade for one or more other BESes? (one of the use cases described  
> in this doc).
> 
> --
> 
> BES-Factory Attributes: TotalNumberOfActivities
> BES-Factory Attributes: TotalNumberOfContainedResources
> These are listed as mandatory attributes. Are they essential to the  
> operation
> of the BES factory?
> 
> --
> 
> BES-Factory Attributes: ActivityReference
> The description says *all* of the currrently contained activities  
> should be
> listed. I would expect in a Grid environment sometimes it would makes  
> sense to
> restrict the ActivityReference list to those activities which the  
> requester is
> authorized to view or manipulate.
> 
> --
> 
> BESExtension
> 
> The list of valid values might be better listed as list of example  
> values. The names should be closer to the extension definitions.
> 
> --
> 
> BES-Factory Operations
> 
>  > If a request fails for some reason that applies to all the  
> specified activities—e.g., due to an
>  > authorization fault—then the BES MUST respond with an appropriate  
> fault response message.
> 
> Is there a reason to require this different fault processing on the  
> service as opposed to folding this into the other fault handling case?
> 
>  > If a request can succeed for one or more of the specified  
> activities then the BES MUST respond with a > vector of response  
> elements, where each element corresponds to the equivalent activity  
> designated in > the input EPR vector. Each response element MUST be  
> either an element describing the results of the
>  > request, as applied to the designated activity, or a SOAP-1.1  
> fault element describing why the
>  > request could not be applied to the designated activity (e.g.,  
> because the EPR could not be resolved
>  > to any known activity within the BES).
> 
> I'm a little nervous about explicitly referring to SOAP 1.1 Fault  
> types in the schema instead of including only BES-specific faults  
> here. Also, the "either" part of the response is not enforced in the  
> XML schema---probably simplest as a choice, though there are many  
> ways to do so in a schema doc.
> 
> --
> 
> CreateActivity Output(s)
> 
>  > CreateActivityResponseType Response: On success, Response contains  
> an ActivityIdentifier (EPR)
>  > identifying the requested activity. An ActivityDocument element  
> MAY be included representing the
>  > current representation of the requested activity. This operation  
> may include a NotAuthorizedFault
>  > SOAP fault in the result element indicating that while the front- 
> end (i.e. BES web service) was able
>  > to validate the incoming user credentials, the back-end would not  
> permit the operation given the
>  > credentials supplied.  This can happen for example when a BES  
> implements its activities by fork/
>  > exec’ing those applications using su.
> 
> Is this fault text correct? It seems odd to describe a fault in the  
> response section (and it doesn't seem to appear in the schema for the  
> service).
> 
> --
> 
> CreateActivity Fault(s)
> 
>  > InvalidRequestMessageFault: An element in the request message is  
> not recognized. The elements that
>  > are not recognized are described in the body of the fault.  This  
> does not mean that the element
>  > itself is in error, but rather that it specifies a syntactically  
> correct value which does not in fact
>  > make sense.  For example, the number of CPUs is represented by a  
> double, so fractional values are
>  > syntactically correct, but would cause this fault to be thrown as  
> they do not make sense in the
>  > context given.
> 
> This seems confusing when compared to the UnsupportedFeatureFault.  
> Perhaps this could be renamed to something containing the word  
> "unsatisfiable" to match more closely the JSDL notational conventions.
> This would also handle the multitude of fault specializations which  
> could reasonably be generated BES implementations (too many cpus  
> requested, insufficient memory, invalid host, etc)
> 
> --
> 
> GetActivityStatuses / TerminateActivities
> 
>  > EPR[] ActivityIdentifier: A vector of zero or more EPRs (obtained  
> from previous CreateActivity
>  > operations)
> Zero doesn't make sense here, does it?
> 
> --
> 
> GetActivityStatuses
> 
>  > Since the BES specification allows for extensible activity state  
> diagrams, it is possible that not
>  > all states within the state diagram will be relevant/meaningful to  
> a particular client. BES requires
>  > that all legal state transitions are transitioned even if they are  
> not relevant to a particular
>  > client. For instance, if an empty JSDL document is submitted to  
> the BES then all the states from New
>  > to Finished will be transitioned through even though there is no  
> underlying specified activity.
> 
> Does this text belong in this section? The New state is not mentioned  
> elsewhere.
> 
> --
> 
> GetActivityStatuses / TerminateActivities
> 
> InvalidRequestMessageFault
> 
> Does this fault make sense for these operations?
> 
> --
> 
>  > TerminateActivityResponseType[] Response: A vector detailing the  
> responses of the BES to the
>  > termination requests. The Terminated element is a boolean value  
> indicating whether the BES
>  > successfully (true) terminated the activity or not (false). If  
> true is returned, then the associated
>  > activity is now in the Terminated state. If false is returned then  
> the activity MAY eventually
>  > transition to the Terminated state. If an activity specified in  
> the input cannot be located or cannot
>  > be terminated for some reason then the TerminateResponse MUST  
> contain a SOAP-1.1 fault element
>  > instead of a Terminated element.
> 
> The interface for this might be slightly more useful if it were to  
> return the activity status instead of the boolean value.
> 
> --
> 
> GetActivityDocuments
> 
> Missing heading + same concerns as in BES-Factory Operations above
> 
> --
> 
> GetAttributesDocument
> 
> The wsdl for this operation doesn't seem to match the description
> 
> --
> 
> BES-Activity Port-type
> 
>  > The BES-Activity port-type defines operations for monitoring and  
> managing individual activities.
>  > These operations are intended to be applied to EPRs returned by  
> previous CreateActivity operations.
>  > Returning an EPR that supports the BES-Activity Port-type is  
> optional in the CreateActivity operation
>  > of the BES-Factory Port-type.
> 
> Actually, this port type is not defined in this document at all. This  
> section is a definition for an activity document which can be used in  
> some messaging by the BES Factory port type.
> 
> --
> 
> Optional Extensions
> 
> Probably helpful to add the extension URIs in the section defining  
> the relevant extensions.
> 
> --
> 
> Idempotent Execution Semantics
> 
>  > Should a BES receive a second CreateActivity request that includes  
> the same identifier as a
>  > previously received request, the BES MUST not create the requested  
> activity a second time if it
>  > already created the activity for the first request
> 
> This should probably read "Should a BES receive a subsequent  
> CreateActivity request"...
> 
> --
> 
> Subscription to Notification Events
> 
>  > A BES that allows its clients to subscribe for messages concerning  
> activity state changes MUST do so
>  > using either the WS-Eventing or WS-Notification protocols.
> 
> Change this to be a MUST only if referring to a BES advertising the  
> SupportsSubscriptions extension.
> 
> Should additionally list the Topic (for wsnt---not sure about WS- 
> Eventing) which should be used for the subscription request.
> 
> wsnt prefix isn't defined in the Namespace table in section 1.2
> 
> --
> 
> Authors:
> Should refer to Argonne National Laboratory not Argonne National Labs
> 
> Since Peter has moved on from Globus/ANL, I'm not sure if Peter Lane  
> should be listed as author based on the criteria discussed in emails:
> 
>  > Greg also takes the view (and the GFSG supports this) that
>  > anyone listed as an author must individually be willing
>  > to take full responsibility for the document, now and
>  > forever.  This will go into the revised GFD #1, too.
>  > It's the important part, in Greg's view.
> 
> --
>   ogsa-bes-wg mailing list
>   ogsa-bes-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg

-- 
Andreas Savva
Fujitsu Laboratories Ltd