[Pgi-wg] YAP - Yet Another Proposal

[Andrew Grimshaw]

Good questions. Answers embedded.

 

> -----Original Message-----

> From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of

> Aleksandr Konstantinov

> Sent: Thursday, May 21, 2009 6:01 AM

> To: pgi-wg at ogf.org

> Subject: Re: [Pgi-wg] YAP - Yet Another Proposal

> 

>  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.

> 

[Andrew Grimshaw] OK - and then fault if the activity was not in that state?

> >

> > 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.

[Andrew Grimshaw] I was not clear. The porttype in the spec has no methods.
The idea is to either overload the one there, or most likely, create a new
porttype. During the debate over BES that was added in by the faction that
wanted to be able to directly communicate with the activities. I think to be
absolutely clear it may need to be a new porttype.

> 

> > MUST support getResourceProperties

> 

> Do You mean OASIS WSRF-RP getResourceProperties? Just clarifying.

> Which properties are going to be provided?

 

[Andrew Grimshaw] This is a hot-potato issue. The real problem is that it
would be very handy beyond BES/PGI to have a single porttype for getting
metadata/attributes. WSRF-RP, and the restricted profile on it in the
OGSA-WSRF-BP (it restricts the class of queries among other things.) 

 

The original BES working group could not come to consensus on using WSRF-RP
in any form. That is why BES has getFactoryAttributesDocument as a sort of
very restricted getProperties. I think now would be a good time to clean up
past mistakes. On the other hand, we could just leave it the way it is and
have getFactoryAttributesDocument return a schema extended with the XML Glue
elements we desire. 

> 

> >

> > 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.

[Andrew Grimshaw] I'm not sure what you mean. Do you mean into the metadata
portion of the EPR? I think this may be difficult. Status information for
example changes? The contents of the session_directory may change. Or do you
have something else in mind?

> 

> >

> >

> > 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?

[Andrew Grimshaw] I mean the proposed "BES-Extensions" porttype described
earlier.

> 

> >

> > 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.

> 

[Andrew Grimshaw] Sorry for being unclear. Let me try to clarify. Create
activity returns an EPR. EPR's refer to some resource endpoint. I'd
suggesting that the resource endpoint MUST support the BES-Activity
porttype.

> >

> > 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?

[Andrew Grimshaw] I think one of the faults that should be specified for the
statetransfer method should be something like "Unknown source state" or
"Unknown destination state". 

 

> 

> >

> > 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.

[Andrew Grimshaw] If you are using OASIS WSRF-RP I believe that you are
supporting the OGSA-WSRF-RP as I believe it is a subset. 

> 

> 

> A.K.

> 

> _______________________________________________

> Pgi-wg mailing list

> Pgi-wg at ogf.org

> http://www.ogf.org/mailman/listinfo/pgi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090521/0cdb8744/attachment-0001.html