[OGSA-BES-WG] BES Last Call
Joseph Bester
bester at mcs.anl.gov
Thu Feb 8 15:11:29 CST 2007
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.
More information about the ogsa-bes-wg
mailing list