[graap-wg] updated draft - composability

[John Rofrano]

> I 
> wondered if this just meant that the document format would be used, and 
> that a different, unrelated messaging protocol would be used.  I'd love 
> to see an example of what this means.

Yes, this means that the document format would be used. The original 
intent of composability with negotiation models was to maintain a 
separation between the agreement and the way in which you arrived at the 
agreement. 

For example: I may run a marketplace or exchange in which providers of 
services advertise that they have capacity to sell and requestors would 
submit their capacity requirements. This exchange is similar to an RFQ or 
reverse auction. In the first round of negotiations, a match-making 
algorithm would be used to match requestors to providers. In a second 
stage of negotiation, the requestor and provider may enter a one-on-one 
negotiation to firm up any agreement details that were not finalized in 
the first stage. So we wanted the actual agreement to remain independent 
and composable with any number of negotiation patterns (RFQ, Auction, 
Reverse Auction, One-On-One, etc.) including multi-stage negotiations that 
combine different patterns.

At least that was the original intent when we wrote that. ;-)

> As I said in one of my public comments (which has been decided against) 
> - the document format is useful on its own and should appear in a 
> separate spec.
> 
> I really think that there are too many different things for this to be 
> one document.

I agree with you. The agreement document is a valuable artifact all by 
itself, regardless of whether you use an AgreementFactory or any other 
means to create it. I also agree that this spec could be multiple specs. 
For example: The Web Service community might want to use WS-Metadata 
Exchange to discover agreement templates and not use factories. So 
discovery of agreements could be a separate spec (or pointer to existing 
discovery specs). Or for that matter, why are agreement templates special 
for agreements? They are an expression of service capabilities and are 
probably more generally applicable as a ?service template? so there is 
another spec. 

WS-Agreement certainly does contain several large thoughts (Agreement 
Document, Agreement Discovery, Agreement Templates, Agreement Protocol, 
Agreement Monitoring, etc.) we should probably just publish what we have 
to get a stake in the ground, and pull it apart later as needed.
 
jr





Jon MacLaren <maclaren at cct.lsu.edu> 
Sent by: owner-graap-wg at ggf.org
04/05/2005 12:38 PM

To
Karl Czajkowski <karlcz at univa.com>
cc
graap-wg at gridforum.org
Subject
Re: [graap-wg] updated draft - composability







On Apr 5, 2005, at 5:32 AM, Karl Czajkowski wrote:
> On Apr 04, Jon MacLaren loaded a tape reading:
>> ....
>> S1.1.1 - P6 - Composability with negotiation models.  I never
>> understood this either.  How would you  "base" a negotiation protocol
>> which required some sort of lengthy interaction on WS-Agreement?  I
>> wondered if this just meant that the document format would be used, 
>> and
>> that a different, unrelated messaging protocol would be used.  I'd 
>> love
>> to see an example of what this means.
>>
>
> I think that is right, at least in the sense that the AgreementFactory
> messages would not come into play. I do think that an Agreement could
> appear (or disappear) as a result of this external protocol, so that
> introspection based on WS-Agreement could happen.  Whether this makes
> sense or not would require a judgement call that is hard to make in
> the abstract...

Ok, so that's not what people mean when they say composability, so this 
should definitely be clarified in the spec.  It's just that someone 
could "base a negotiation protocol on the WS-Agreement document 
format".  This is a much less bold claim - but it's probably about as 
far as you can realistically go.

As I said in one of my public comments (which has been decided against) 
- the document format is useful on its own and should appear in a 
separate spec.

I really think that there are too many different things for this to be 
one document.

> karl
>
> -- 
> Karl Czajkowski
> karlcz at univa.com

Jon.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050406/9f2b077c/attachment.html