[ogsa-bes-wg] Attempted distillation of "Questionsandpotential changes to BES, as seen from HPC Profile point-of-view"

[Peter G. Lane]

Marvin Theimer wrote:
> I believe that today’s reality is that you can’t assume universal WSRF 
> or WS-Transfer support anytime soon. 

Fair enough, I've come to terms with this. ;-)

> I didn’t mean to advocate that there be an explicit accessor function 
> for only the activity status property.  Rather I was advocating that 
> there be accessor functions for each of the properties and that the 
> interop standard mandate that there be at least the accessor function 
> for returning an activity’s status (in addition to the accessor function 
> for returning all the state information for an activity).  All other 
> accessor functions would be part of extensions. 

I think I see what you're implying now. The absolute minimum interop 
would have to include a way to get the status so the user knows at very 
least whether the activity has finished. If the user can't get the 
values of any other properties, the job can still be monitored. I buy 
that. We should probably define the accessors explicitly in an extension 
spec.

> 1) Have named accessor operations for each property and one operation
> 
> for obtaining the entire public state document, or
> 
>  
> 
> 2) Have a single, generic operation that fetches either an array of
> 
> properties or the entire set of public state properties.
> 
>  
> 
> I would advocate taking approach 1 for the following reasons, derived 
> from an explanation of a colleague of mine recently provided me:

This is fine with me.


So to summarize...

----------------
There are four implementation options that should be supported by the 
spec for obtaining public state data:

1) WS-Transfer,
2) WSRF,
3) public state accessor operations,
4) basic interop.

An accessor operation for obtaining the activity status MUST be included 
in each of the above implementation options.

Official QNames SHALL be defined for options 1-3.

The GetInteropData operation MUST return a list of QNames that 
represents which of the above options is supported. An empty list 
implies that ONLY option #4 is available.
----------------

We should also define what port types option #2 implies or break it up 
into three different options for each of the three port types used for 
resource property queries in WSRF (wsrp:GetResourceProperty, 
wsrp:GetMultipleResourceProperties, and wsrp:QueryResourceProperties).

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3804 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060628/52229847/attachment.bin