[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPP A
Brian,
You said: " Keepling related messages together is simply accomplished by
the unique id on the CPA being negotiated and, if necessary (but hopefully
not), the conversation ids on the message headers."
I'm not sure whether you sent this before or after yesterday's negotiation
conference, so please excuse me if I repeat something from the call.
I don't understand why you say "hopefully not" with regard to conversation
IDs. In today's Internet extended transaction environment, a unit of
business may involve multiple messages exchanges, strict choreography
rules, and other related information. The main purpose of BPSS, in my
mind, is to provide a model for expressing extended transactions.
Middleware can provide valuable application-independent support to the
applications in managing these extended transactions including choreography
enforcement and recovery of individual in-progress units of business
following a system failure. However, application-independent middleware
requires application-independent identifiers for routing, monitoring, and
control. The whole purpose of the conversationId is precisely to identify
the stream of messages that constitute a single unit of business (i.e. a
single execution of the BPSS instance model), to enable the middleware to
understand the connection among the messages. Use of the conversationId
permits middleware to distinguish among multiple concurrent instances of
the abstract unit of business and to track and control them separately
without having to peek into the payload to find application-specific
identifiers (which would hardly be application-independent).
In my mind, the conversation is a natural way to manage the negotiation
process. A single instance of the negotiation process could either be a
single conversation or perhaps a sequence of converations punctuated by
phone calls.
Making use of the conversation construct is an essential component of being
able to treat the negotiation process the same as any collaborative
business process.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Hayes, Brian"
<Brian.Hayes@Comme To: ebxml-cppa-negot@lists.oasis-open.org
rceone.com> cc:
Subject: RE: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPP
03/13/2002 03:31 A
PM
Lengthy response. I will keep my comments realitive to the Collaboration
Protocol Agreement Simple Negotiation [CPA-SN] model that I just sent out [
http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00025.html
].
1 Race Conditions
==================
1.1 New Offer Scenario
----------------------
> As to (1), we can't avoid that but we still need to figure out
> who gets the ball next if the two parties have both each other
> sent initial requests.
[
http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00012.html]
Description: Party X and Party Y not having done business together, or wish
to establish some other CPA for a new aspect of some business, concurrently
send CPA offers to each other.
In this case, there are two (or more) offers corresponding to the uniquely
identified CPAs in each offer (uniqueness as definied by the tuple {CPA id,
id of party offering the CPA}). The CPA negotiation application should be
smart enough to catch this situation of *apparently* concurrent offers,
raise a flag, and then let the humans take over. After all, the business
goals of the offered agreements may be completely different (you could have
multiple CPAs between the same parties for different purposes). In other
words, in this scenario, you don't know that the offered CPA are for the
same purpose until you compare them.
1.2 Concurrent Counter-Proposal Scenario
----------------------------------------
Description: Party X and Party Y both send CPA counter offers after a CPA
offer/counter-offer has been rejected (by either party).
The CPA-SN model does not allow this. The situation of a party that sends
an offer/counter-offer out of turn is easily detected through the
application of the model which also requires that the offered CPA has a
unique identifier that both parties must use in the collaboration instance.
If a party changes the CPA id, then by definition, a new CPA Simple
Negotiation collaboration has been initiated.
2 Reject-with-Counter-Offer-Advice with Counter Proposal
=========================================================
>2. packaging this counter-pending response with the new request
>providing the proposal (plus NDD if needed)
> --to cut down on message traffic,
> --to keep related messages "together"
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00015.html
]
>1. Can I send, in one message, both my counter-pending
>and my proposal? If not, why not?
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00011.html
]
With CPA-SN, counter proposals are NOT packaged in the offer response
message (which includes the Reject-with-Counter-Offer-Advice reply. Bob
and Dale have discussed this in
http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00014.html,
http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00016.html.
This constraint is what makes the CPA-SN model not-complex and easily
implementable -- the model could be easily implemented by a some hosted
application on some website where the "messaging" is between web browsers
and the application. Simplicity out-weighs message traffic for this model.
Keepling related messages together is simply accomplished by the unique id
on the CPA being negotiated and, if necessary (but hopefully not), the
conversation ids on the message headers.
TO DO: in the CPA-SN model, the CPA Offer Response needs to contain the CPA
id of the offered CPA.
3 Proposing/Accepting a Previous Offer
=======================================
>2. Can I send later an Accept for the original
>proposal? (After my counter got nowhere).
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00011.html
]
> Dale> It may not be necessary to do this, but one of
> our use cases for counterproposals is that a proposal
> has come in that is acceptable to us, but we think
> that there is another that is preferable.
[http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/msg00018.html
]
With CPA-SN, you simply offer the original offer or a previously rejected
offer when it is your turn. I would recommend providing a note on the
offer stating what is going on. Note that I interpreted "proposal" as
"offer" in my readings of the above quoted text. CPA-SN does not have a
proposal collaboration (which is partially modeled in the ebXML E-Commerce
Patterns [bpPATT] technical report).
TO DO: in the CPA-SN model, the CPA Offer and CPA Offer Response needs to
contain note elements.
The CPA-SN assumes (but does not require) that there are humans (or perhaps
monkeys) evaluating the offers/counter-offers. More than likely, the
negotiating parties will do some of the negotiation discussion in
teleconferences, in person, or other not-modeled means. We could put this
interaction into the model and I have often thought that some audiences
need it for some models (for example, sellers can send order responses that
act as change orders -- what is missing from most models of this process is
the phone call where the seller calls the buyer and asks if it is okay to
change the order). In any case, since we probably want to allow the
collaboration to not require "out-of-band" communication, the offer and
offer response messages should allow for notes.
4 Issue of Non-Terminating Negotiation
======================================
I think it was Dale who pointed out the scenario of the non terminating
offer counter-offer negotiation. I know that there are negotiation
techniques to handle this; but, it is out of scope for the CPA-SN. Some of
these techniques could be employed in a proposal collaboration (the CPA-SN
only includes the Offer).
The parties can employ simple or sophisticated CPA negotiation application
that uses the CPA-SN. This application can can keep track of previously
offered CPAs to offer advice and to help prevent the non-terminating
negotiation. A simple application may not contain this functionality and
the user may need to rely on memory and previously hard-copied offers to
see that the negotiation is not terminating in a timely fashion.
Let us not forget the telephone, e-mail, and the note elements on the
messages that can be used to discuss the situation with the other party.
5 Scope of CPA-SN (Collaboration Protocol Agreement Simple Negotiation)
=======================================================================
The CPA-SN is modeled after the Simple Contract Formation Pattern as
specified in ebXML E-Commerce Patterns [bpPATT] technical report ([bpPATT]
also discusses more complex patterns). CPA-SN may not meet all the
requirements documented in the CPPA Negotiation Requirements document. If
this is the case, I would recommend that the CPPA Negotiation team have
more than one CPPA Negotiation business process. Adopt a simple one, such
as CPA-SN, as soon as reasonably possible and then later develop more
sophisticated ones.
Best Regards,
Brian
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC