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