[OGSA-BES-WG] BES Last Call

[Christopher Smith]

Comments for some of the issues inline ... not sure I have answers for all
of them. 

-- Chris

On 08/2/07 13:11, "Joseph Bester" <bester at mcs.anl.gov> 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?
> 
It is intended to be extensible. The context should be clarified by
referring to the factory attribute.


> --
> 
> 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.
> 
So I actually found the description quite clear. The text says that the
specialization must support both 1 and 2. 1 says that you can define
whatever state diagram you want within the confines of the specialized
state, and 2 says how your sub-states transition into the rest of the
unspecialized state diagram. I can't explicitly allow transitions to
substates of S (i.e. other specializations) because my specialization only
has explicit knowledge of the state it's specializing and the unspecialized
state diagram that is described in BES.

> --
> 
> 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)
> 
Well ... the BES may have any number of internal states that it uses to
implement it's functionality. The point is that the client sees the
published state diagram, and any specializations that it chooses to
understand. 

Good point on TerminateActivities ... it should be listed as one of the
faults.

> --
> 
> 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.
> 
Yes ... a non-normative example would be useful.

> --
> 
> 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.
> 
It was a placeholder, but no attributes were defined. The bits in the
parentheses should be removed.

> --
> 
> BES-Factory attributes
> 
> General note: not all attributes in the table are listed in the schema
> (I noticed TotalNumberOfActivities and
> TotalNumberofContainedResources were
> missing)
> 
I apologize ... must have been some kind of cut and paste error, as these
elements are definitely in my schema.

>> 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>
> 
It is intended to be the second. It is stated in section 6.1.7 that this is
the case, but I guess it's not clear enough. Can you suggest some
alternative text?

> --
> 
> 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).
> 
Sounds like a decent idea, but I forsee multiple implementations of even
this use case, so I think it's better to leave this up to the
implementation.

> --
> 
> BES-Factory Attributes: TotalNumberOfActivities
> BES-Factory Attributes: TotalNumberOfContainedResources
> These are listed as mandatory attributes. Are they essential to the
> operation
> of the BES factory?
> 
Yes. The text does not mandate that the BES must return the list of activity
references or contained resources (e.g. maybe it would choose not to return
details due to authorization constraints). Having these counters available
means that a client can distinguish between no activities in the BES, and
activities that it isn't being shown.

> --
> 
> 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.
> 
Right ... I agree that the text should be clarified.

> --
> 
> BESExtension
> 
> The list of valid values might be better listed as list of example
> values. The names should be closer to the extension definitions.
> 
Yes ... the text should be clarified.

> --
> 
> 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?
> 
Can you clarify "other fault handling case"? Do you mean the operation
returning a fault? If so, the reason is that there is a vector of inputs,
and a sub set of the vector might succeed, so that the operation can
succeed, but individual activities need to be flagged for faults.

>> 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. 
A little nervous, or nervous enough to suggest an alternative. :-) It's just
a rendering question.

> 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.
> 
Some feedback received from Microsoft's Web Services team indicated we
should avoid 'choice'. Can you provide an example of how you would like to
see this rendered?

> --
> 
> 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).
> 
The text should be moved to the fault section.

> --
> 
> 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)
> 
Seems like a nice clarification. I'd be ok with it.

> --
> 
> GetActivityStatuses / TerminateActivities
> 
>> EPR[] ActivityIdentifier: A vector of zero or more EPRs (obtained
> from previous CreateActivity
>> operations)
> Zero doesn't make sense here, does it?
> 
True ... I would make minOccurs=1".

> --
> 
> 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.
> 
An artifact from an older version. I would vote for the removal of this
text.

> --
> 
> GetActivityStatuses / TerminateActivities
> 
> InvalidRequestMessageFault
> 
> Does this fault make sense for these operations?
> 
Yes, since all messages allow for extension content. Maybe it also needs
unsupported feature?

> --
> 
>> 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.
> 
I agree.

> 
> 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.
> 
A placeholder ... should be cleaned up.