Re: [ogsa-hpcp-wg] [OGSA-BES-WG] BES Last Call
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@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.
--
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
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
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
Composition of Specializations [1] and Specialized Fault Responses [2] [1] the the 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 activitiese.g., due to an authorization faultthen 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.
Christopher Smith wrote:
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. [...] 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.
If memory serves, there's actually a formal name for this sort of thing. The specialization must be Weakly Similar to the general state diagram. This means that every state in the specialization must be mappable to a general state, and that every transition between states in the specialization must be either mapped to a transition between equivalent states in the general diagram, or that the two states must be mapped to the same general state and that the transition between the two must be not observable using just the general transitions. Or at least I think that's Weak Simulation (I know we don't want bisimulation; that's too strong) and I think I've got it the right way round. Too long since I last worked with these things in detail. My real point though is that someone's already formalized the notion we want to use; it captures exactly what we want. Donal (this formal CS stuff is occasionally useful :-)).
participants (2)
-
Christopher Smith -
Donal K. Fellows