RE: quote use case

Len

I've looked at your use case and think that there are several things going
on.

IT's A PRIVATE BUSINESS PROCESS
Firstly, the use case is written from the perspective of the supplier. Who
has several sets of relationships a) with the buyer, and b) with each
manufacturer.

Secondly, only the supplier has relationships with other other roles, i.e.
the manufacturers don't talk with any other manufacture nor the buyer, and
the buyer only talks to the supplier.

Thirdly, the Supplier is in complete control of all the interactions once he
receives the initial request for quote from the buyer.

These characteristics: one-on-one relationships and control by a single
role, are all the characteristics of a "private business process" which is
ideally defined by a language like BPEL.

IT's SEVERAL CHOREOGRAPHIES COMBINED
That said, there actually three choreographies going on all under the
control of the supplier:
1. The negotiation protocol between the buyer and the supplier,
2. The request for quote protocol that takes place between the buyer and
supplier once the negotiation has successfully completed, and
2. The price and availability protocol between the supplier and the
manufacturers to gather the information to put in the quote.

I also think that there are benefits all round if these choreographies are
defined separately as it would allow different choreographies (i.e. message
exchange sequences) to be used depending on the capabilities of each
participant.

SEPARATE "QUALITY OF SERVICE" FROM THE CHOREOGRAPHY DEFINITION
You also mention in your use case that "some of the key features that must
be accounted for in the choreography include:
. Contract provisions, including
. Service level agreements 
. Security provisions
. Privacy provisions
. Non-repudiation"

Although these are important to a specific implementation, the actual
service levels, security, privacy etc that are used could vary from
implementation to implementation and even from instance to instance.

If the sequence of exchanging messages and these "quality of service"
attributes are combined into a single "choreography definition" then the
number of choreography definitions you will need will explode because of the
variation of "quality of service" attributes that will necessdarily occur.

I think a better approach is for the choreography defininition to define
*just* the sequence of exchanging message. The quality of service levels can
then be added when that choreography definition is "bound" to a specific
implementation.

Thoughts?

David
 

-----Original Message-----
From: Len_Greski@grainger.com [mailto:Len_Greski@grainger.com]
Sent: Monday, June 16, 2003 9:45 AM
To: bob.haugen@choreology.com
Cc: public-ws-chor@w3.org; public-ws-chor-request@w3.org
Subject: Re: quote use case






Robert wrote:

Len Greski posted the interesting Request Quote use case.
I have some questions and comments:

1. Is this use case based on actual practice?
It has a realistic air about it (unlike some use cases)
but are all the details from actual practice?
If so, then I find it even more interesting.
If not, does it represent something like
desired or to-be practice?

Yes, this use case is fairly close to actual current practice.

2. You wrote that in this use case,
"the contractual relationships between Supplier and Manufacturer roles
are already in place."
I assume that means the contractual relationships
between Supplier and Buyer are *not* in place,
and the use case is the opening of contract
formation between Supplier and Buyer?

Correct. The request for a quote begins the process of contract formation,
as the Supplier makes a commitment that the quote is valid for <n> days.
The fact that a quote is offered, however, does not obligate the Buyer to
purchase.

3. Jumping around a bit, you wrote,
"Need to distinguish the idea of a contract between services ... from a
legal contract."
Tony Fletcher and I collaborated on a paper about
a somewhat related use case in trying to harmonize
OASIS-Business Transaction Protocol and UN/CEFACT
Business Collaboration Protocol:
http://www.supplychainlinks.com/UNCEFACT-papers.htm
In that paper, we distinguised between:
* Economic Contracts, about commitments to exchange
economic resources, e.g. products and money; and
* Transaction Contracts, about the rules of engagement
for doing electronic commerce.
Whether you buy that terminology, the distinctions in the paper
might be useful.
Economic Commitments can be defined precisely.
Contracts can contain both Economic Commitments
as well as Transaction Contracts, which is where
the going gets muddy.

Thanks for the reference, I'll take a look at your paper. On the
teleconference last week, we had some discussion were we used the word
contract. The term means different things to different people, and we need
to distinguish what it means for the choreography specification, versus its
business meaning (a legal agreement between two parties blah blah blah...).
The distinction in your paper, economic vs. transaction, may be useful in
helping us clarify our use of the word.

4. Getting back to the scenario,
I don't see where the Buyer accepts the Quote.
In other words, I don't see where a contract between
Buyer and Supplier is legally bound.
The Quote appears to be binding on the Supplier for some timespan,
and presumably if the Buyer accepts it they have an Economic Contract.
But not until?

I specifically left out the activity where the Buyer and Supplier convert
the quote into a contract. In many situations the relationship between
Buyer and Supplier is relatively informal, i.e. the Buyer can buy off the
quote for a specified period of time without entering into a formal
contract. In other situations acceptance of the quote triggers more
elaborate contracts process.

5. Might the Buyer be getting quotes from many Suppliers,
and accepting the best one?

Yes, this is possible. I scoped the use case at a relationship between a
single Buyer and a single Supplier, because this is complex enough to cover
the key features that must be handled by the choreography specification
(contract provisions, service level agreements, security provisions,
privacy provisions, non-repudiation, escalation procedures, exception
handling), without being overly complex.

6. "The Supplier may reject one or more terms requested by the Buyer. To
handle the negotiation of terms, there may be multiple request /
response sequences between Buyer and Supplier."
Very difficult to present as a linear event sequence,
and I see that you did not try to do so.
How would you handle that negotiation?
If this use case is from actual practice,
how *do* you handle it?
There's a saying, "everything is negotiable".
I think that means in a business conversation,
every point of agreement may resolve into a negotiation.

I know how it happens in "meat space", but haven't figured out how to
handle this electronically. We'll have to think about this further because
most electronic negotiation models that I know about are require some kind
of human interaction (e.g. auction sites), or are very restricted in the
parameter(s) being negotiated (e.g bid/ask on securities). Hopefully one or
more of our erstwhile colleagues on the list will provide an answer to this
one...

regards,
__________________________________
Len Greski
Director
eBusiness Architecture & Development
W.W. Grainger
voice: (847) 793-5185
fax: (847) 793-5019
cell: (847) 366-1376
mailto:greski.l@grainger.com