[graap-wg] updated draft - symmetry

[Jon MacLaren]

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 at univa.com

Jon.