On Apr 5, 2005, at 5:42 AM, Karl Czajkowski wrote:
On Apr 04, Jon MacLaren loaded a tape reading:
Hi Karl,
Comments specifically regarding symmetry. Overall, I think that the spec needs an example working through a case where the initiator is the service provider. I think that there are still gaps in people's understanding about this. Let me know if you need some text - I should be able to find something I've written-up previously about this type of thing.
I agree it needs presentation. One thing though: symmetry in the sense of the initiator-side Agreement facilities is not the same as the "role-reversal" you are describing. We could have a totally asymmetric client-server Agreement where the initiator represents the domain service provider and the responder represents the consumer.
We need good terms to distinguish these different ideas...
I mentioned symmetry issues to the group a couple of years ago, and I meant that it should be possible to have provider-initiated agreements as well as consumer-initiated. So I can claim first use of symmetry within the GRAAP context, if that counts. (I don't suppose it does.) All my comments were supposed to be about this, and not the initiator-side Agreement stuff (which I didn't read). I hope everyone can read them as such.
Section 8 (which I think should be put into Section 3 - the section on how WS-Agreement *works*).
OK, I was trying to get new content down on the page and not worrying so much about position.
Yeah - it was just a suggestion for later on.
In the 2nd paragraph, you say that "the obligations in the agreement are not dependent on the initiator being informed of the decision". If the initiator is the service provider, bidding for work, then this statement cannot be true. You must learn whether your bid has been accepted (and also, presumably, receive/retrieve the precise specification of the work to be done).
We need to resolve this, as it tells me that the role reversal cannot be supported. :-(
Well, I've explained a number of times (a long time ago) why I think that this is important. I don't know if it's important to anyone else, though. Does someone else want to say something here?
This text I added was intended to trigger such discussions; it is as explicit of a summary as I could write to capture the results of all those "commitment protocol" discussions we had over the years. As I see it, the initiator (whether a domain specific provider or consumer) must proceed speculatively until he knows for sure. It's the inherent "damned if you do, damned if you don't" hazard of the online binary decision problem; we decided explicitly to always make the initiator the one who "takes the risk" after deciding that role-reversal was equivalent to the more elaborate "solicit/pre-commit/commit" handshake we had before.
I do not understand the comment about receiving the "precise specification of the work to be done". If the provider is the initiator, he ALREADY HAS this when he makes the createAgreement or equivalent call. Where he gets it is out of scope, but one assumes it would be from some advertisement system where he saw the "call for bids".
Yes - that's fine if the entire job description is what is bidded against, and it probably would be. If you try to follow your suggested semantics, with the obligations being independent of the initiator being informed, then I suppose that in the absence of a decision, the bidder could speculatively continue, and start executing the job. They could then discover the result later. But I don't think it makes sense to do so. I think perhaps that this is a consequence of the lack of phased commit in the protocol. You don't have the idea of a consensus being arrived at between the two parties. I'm not convinced that there's any benefit in adopting the semantics you propose. And I'll be really interested to see if it turns out to be suitable for co-scheduling.
.... Good point, should it show initiator and responder-side entities with bidirectional arrows? Or do we need an expanding set of diagrams showing different permutations? I think we should stay generic and depend on "primer" work to spell out a dozen use cases.
I don't have any useful suggestions here, other than to state that, if you're going to support the "role-reversal" case, the diagram is not generic as it stands. And I'd feel a lot happier about the primer answer if this actually existed. There's been stuff heading for the primer for two years now. I hope someone's been writing it down.
karl
-- Karl Czajkowski karlcz@univa.com
Jon.