Good questions. Answers embedded.
> -----Original Message-----
> From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of
> Aleksandr Konstantinov
> Sent: Thursday, May 21, 2009 6:01 AM
> To: pgi-wg@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
> 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@ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg