[graap-wg] updated draft - symmetry

[Karl Czajkowski]

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...


> 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.


> 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. :-(

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".



> Other symmetry-related comments from earlier in the spec.
> 
> S1 - P5 - assumption of roles.  I was trying to think of some text to  
> suggest for this.  But I think that you are in trouble before you get  
> here.  Reading the first couple of paragraphs again, I think that you  
> need to state somewhere in there that the "creational offers" (a phrase  
> which I really don't like!) can be made by either party.
> 

Yes, I think we can work on this more if necessary.  You are
commenting on text that I haven't modified, right?  I'm pretty sure I
didn't coin "creational offers". :-)


> (Incidentally, I still feel, and always have, that there are  
> obligations on both sides in reality.  The consumer is agreeing to  
> consume the service, e.g. provide the work in the case of the job  
> submission example, and also to provide payment of some sort.  I note  
> that the specification still views that all obligations are on the side  
> of the service provider.)
> 

I agree with you that there are obligations on both sides, but I do
not think the group nor the specification says otherwise.  If
anything, it just isn't explicit enough yet.  So this is a
presentation issue, not a debate which needs to be settled...


> S3 - P10.  The other problem with the diagram is that it completely  
> links the initiator and consumer roles.  I agree with the comment about  
> removing the factory - I think that this pattern is often not present.
> 
> Jon.
> 

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.

karl

-- 
Karl Czajkowski
karlcz at univa.com