> 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@cct.lsu.edu> Sent by: owner-graap-wg@ggf.org
04/05/2005 12:38 PM
To
Karl Czajkowski <karlcz@univa.com>
cc
graap-wg@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@univa.com