[Pgi-wg] YAP - Yet Another Proposal

[Aleksandr Konstantinov]

 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.