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

21 May 2009

      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 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@ogf.org
...
http://www.ogf.org/mailman/listinfo/pgi-wg