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

[Peter G Lane]

On Tue, 2006-06-20 at 11:48 -0700, Marvin Theimer wrote: 
> Hi;
> 
>  
> 
> I have to admit that I had to read up on WS-Transfer. It makes more
> 
> sense where you're coming from now. It's a very different philosophy
> of
> 
> how resource state should be managed. Considering this I think we
> should
> 
> still make this activity description a resource state property/element
> 
> and leave it ambiguous as to how it is accessed. Unfortunately if we
> 
> don't define the Activity interface we can't define the state item.
> 
>  
> 
>       ...
> 
>  
> 
> And here is where I have the biggest problem with WS-Transfer. I think
> 
> an activity's progress state should be a property that is modeled as
> 
> desired (i.e. either WS-Transfer or WSRF) as long as there are
> multiple,
> 
> popular ways to do so; but as you say, getting the entire state for
> one
> 
> item is excessive. That's my personal opinion in general after reading
> 
> about WS-Transfer. I don't think we should be sacrificing good design
> 
> just because some implementation detail (I consider this
> implementation
> 
> because it's left ambiguous in the spec) doesn't play nice. If you
> don't
> 
> like it, don't use WS-Transfer in your implementation.
> 
>  
> 
> Now then, there is a potentially serious problem here in that if the
> 
> public state model is not standardized in the spec then how do you
> know
> 
> what WS interface to use to manipulate it? In that case I would say we
> 
> need an operation that specifically targets interop data (kind of like
> 
> the FTP "FEAT" command). This is yet another reason in support of
> 
> defining the activity interface. Each activity ought to be exposing
> via
> 
> such a method what kind of public state model it uses.
> 
>  
> 
> I agree that we should define the activity interface since we’re
> implicitly doing so at the BES level now.  Leaving the access method
> ambiguous unfortunately doesn’t yield an interface that actual
> implementations can interoperate through.  So the HPC profile work
> will need to define one or more concrete interfaces one way or the
> other.  

I fully agree with this. The only use of the GetInteropData operation in
this case would be to tell you whether you *can* interoperate with it.

> Consider also that currently the main development tool options support
> either WSRF or WS-Transfer or neither.

The "neither" option is what frustrates me reading this. We want to
expose public state, and yet apparently we have to keep implementors in
mind that have no standard way to expose that public state.

>   So developers would need to implement compliant implementations of
> either WSRF or WS-Transfer or both on their own.  If you’ve followed
> the interop workshop process that Microsoft and IBM have been using
> for achieving interoperable tooling and implementations of even basic
> Web Service concepts and protocols, you’ll know that that’s a
> seriously expensive commitment to impose on developers.  When you
> consider that in a couple years’ time the world will have converged on
> a merged alternative to both of these protocol suites (and associated
> tooling), it seems even more questionable to pursue this avenue at
> this point in time.

I reluctantly agree. I was operating under the assumption that at very
least either WSRF or WS-Transfer would be an acceptable requirement. Not
having any public state model requirement at all makes this a slightly
different problem in my opinion.

> The alternative that I would advocate is to define a placeholder
> interface for version 1 that skirts the issue altogether.  That was
> the intent behind my straw man proposal of  GetActivity and
> GetActivityState methods.  Using these would allow BES and the HPC
> profile work to get off the ground quickly without requiring that all
> parties first create compliant implementations of both WSRF and
> WS-Transfer.  Interoperability testing would be confined strictly to
> these few methods in the BES/HPC-profile context and hence would be
> much simpler.  Whether these methods should be replaced by the
> convergent replacement for WSRF/WS-Transfer in a later version of BES
> is something that could be examined at a later time when that
> convergence has actually occurred and things like tooling are broadly
> available for it.

I think I'm with you now for the most part. I just have a problem with
singling out one property over another in terms of which ones are "good
enough" to have their own accessor operation. Especially if we allow for
notifications, the activity status might be the least used and yet you
are proposing that we make it the only property that gets it's own
accessor operation. Perhaps it would be acceptable to create a hybrid
operation that either takes an array of property QNames and returns
those properties (ala WSRF's "GetMultipleResourceProperties"), or if the
array is empty/not specified returns the entire public state document
(ala WS-Transfer's "Get"). If we need a multiple-activity operation for
the BES services, then just add another argument that is an array of
activity EPRs and name the operation to distinguish it from the singular
operation.

> I’m not sure I understand what you mean by “leave the public state
> model ambiguous”.

I meant define public state properties in the spec like we do, but leave
it up to the implementation as to whether to use WSRF or WS-Transfer to
access those properties. The GetInteropData operation would indicate
which public state model is implemented.

>   Are you referring to the fact that BES has decided to move to an
> extensible state model and you’d like to use your proposed
> GetInteropData to return – among other things – a description of which
> state model extensions the service implements (including, of course,
> the base state model)?  If that’s the case then I totally agree with
> the need for that information.

The term "state" is used both for the description of what vertex the
job/Activity is at in the directed progress graph as well as the set of
data elements/properties that are associated with a statefull service
entity. When I say "public state" I mean the latter. I'll try to use
"activity status" for the former from now on.

> So I suspect that we’re in agreement that, one-way-or-the-other, an
> activity should expose at least the following state elements for
> querying by clients:
> 
> ·       Description of which state model extensions the service
> implements.

I presume you're referring to what I'm calling the "public state model",
yes?

> 
> ·       Activity state.

Not sure what you're referring to here.

> ·       Full (extensible) description of the activity’s state.

And by this you mean the extensions to what I'm now calling the
"activity status"?

> See my previous comments about not wanting to expose more than one way
> to retrieve the public state of an activity.  Please also note that,
> whereas one can argue about the pros and cons of the WSRF and
> WS-Transfer approaches, the reality I have to deal with is that there
> are two camps and there is no good tooling that supports both, so the
> choice the HPC profile WG has to make is arguably one of the
> following:
> 
> 1.      Go with both WSRF and WS-Transfer-based versions of BES and
> force everyone to implement compliant versions of both.  That’s too
> expensive in my opinion.
> 
> 2.      Wait for the convergent follow-on specs and define BES in
> terms of those.  That doesn’t meet the time-line requirements that the
> HPC profile WG faces.
> 
> 3.      Define a single interface that employs neither WSRF nor
> WS-Transfer in order to get a version 1 HPC profile done now rather
> than in a couple of years time; then consider for version 2 whether it
> makes sense to move to the convergent WSRF/WS-Transfer follow-on
> specs.  
> 
> To me, option 3 seems by-far the most preferable one.

This is essentially what I was pushing with my ambiguous public state
model concept. What I wasn't considering was this new (at least to me)
requirement for no public state model at all. If we can't assume a
public state model, then we have to basically agree on some minimal
reconciliation between WSRF and WS-Transfer since the BES spec implies
some sort of public state model as a result of it's definition of
statefull service properties. The two candidates seem to be the
following:

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.

Is that a fair assessment?

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060620/329cf10f/attachment.bin