[Pgi-wg] YAP - Yet Another Proposal
Aleksandr Konstantinov
aleksandr.konstantinov at fys.uio.no
Thu May 21 05:01:04 CDT 2009
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.
More information about the Pgi-wg
mailing list