Hello, On Wednesday 20 May 2009 18:46, Andrew Grimshaw wrote:
All,
(Note: I started this email before the call - I will finish it but do not believe it will change any minds.)
I think defining IDL's will lead to non-interoperation without significant work on wire format .. think CORBA and its failure until IIOP happened.
That said, here is a concrete proposal.
Start with BES AS IS
Create a new porttype BES_Extensions that defines two new functions
ActivityResonse [] CreateActivitySet(ActivityDocument []) - based upon the BES create activity
The activity response is an EPR or a SOAP 1.1 fault message element
Define a StateTransferElement to be a <EPR, Destination_state) where destination state is a string formatted as per the BES specification
I suggest (as it was already suggested) to add optional Source_state for specifying state of activity which is expected to be when request is received. It's purpose is to avoid race condition.
Define a TransitionResponse to be a <new_state_string | SOAP1.1 fault message)
TransitionResponse [] StateTransfer (StateTransferElement [])
Profile ActivityEndpoint porttype
Did You mean BES-Activity porttype as defined in BES specs? If yes then it shoudl probablt be to create BES-Activity porttype. BES specs does not define any WSDL or schema for that port type. And few words in plain English is not enough to define one.
MUST support getResourceProperties
Do You mean OASIS WSRF-RP getResourceProperties? Just clarifying. Which properties are going to be provided?
MUST support RNS:list
RNS:list MUST return a predefined set of <name, EPR> pairs that contain the job information people want, e.g., session_directory, status
I would prefer to have that information profiled directly into EPR of activity. That would save a need to call at least one more operation for every initiated Activity.
Then create a PGI-Basic-Profile
Conformance targets
MUST handle HPC-BP, HPC-FSE (implies MUST support BES 1.0 FactoryPortType and JSDL)
MUST support BES-Extensions
Which?
MUST return EPRs to resources that support ActivityEndpoint
I assume ActivityEndpoint is BES-Activity. Otherwise ignore rest. I'm not sure that You mean by that. Do You suggest Address element of EPR point to URL where BES-Activity porttype is supported or are those EPRs to be sent to BES-Factory as defined in BES specs.
MUST support state model profiles for staging, suspend, whatever_you_want_to_call_the_states_for_ARC if corresponding mechanism is supported
How about client induced state transitions which are out of BES model?
MUST support ActivityDocument element <StartInPending>
In ARC we also support delayed start of activity processing. I guess other projects could come with more elements to be put there.
MUST/MAY support notification - we can argue this out - I do not have a strong feeling - we support it, but we also poll
I would suggest that we have a separate conformance claim supporting RNS directly.
This leaves one big question: How to handle GLUE?
For this to be answered requires that the specific elements of GLUE2 to be indentified.
Keep in mind the BES authors anticipated GLUE finalizing at some point.
That said we either simply add the desired GLUE XML attributes to the results returned from getFactoryAttributesDocument, create a new function that returns just the GLUE, or perhaps better yet support getResourceProperties (I'd recommend using OGSA-WSRF-BP, it is supported in Teragrid and caGrid in the US, also I think by Unicore, and by Genesis II) and return the GLUE XML as resource properties.
In ARC we are using OASIS WSRF-RP for providing Glue2 document as one of properties. We are using own set of properties but can probably switch to OGSA-WSRF-BP. A.K.