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

[Marvin Theimer]

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.  

 

One approach is to reflect the schism between WSRF and WS-Transfer and
define two separate (but equal :-)) interfaces that each employ one or
the other approach.  Unfortunately that will make interoperability in
practice much harder to achieve.  To interoperate with BES services in
general would require that either services export both interfaces or
clients implement both interfaces.  We've effectively doubled the cost
of creating BES interfaces, including all the interop testing that has
to go with it.  Consider also that currently the main development tool
options support either WSRF or WS-Transfer or neither.  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.

 

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.

 

 

To summarize what is essentially a counter proposal, I think we need

to...

 

1) Expose public state as it was intended to be exposed (i.e. in state

properties/elements within the state document)

2) Leave the public state model ambiguous

3) Define the Activity interface

4) Include an interop data fetch operation, say "GetInteropData", on

both the BES interface and the Activity interface. The returned data

should be well defined but extensible, and include what type of public

state model is being used.

 

I'm not sure I understand what you mean by "leave the public state model
ambiguous".  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.

 

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.

*        Activity state.

*        Full (extensible) description of the activity's state.

 

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.

 

Marvin.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060620/7cd22e6f/attachment.html