[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
The issue with conversation ids (as I understand or misunderstand them), is that their scope is constrained by some boundry of a business collaboration model (e.g. BPSS instance) and the scope of the business entities/objects in the business collaboration model or models. I have not given enough thought to what are the exact constraints and boundries. So, now that I have gestured at this at a high level, lets look at some examples...
If I we take a set of RosettaNet PIPs covering the Order to Shipment Notice to Invoice chain and we treat each PIP as its own BPSS, what are the conversation ids set to for each collaboration instance? Are they the same or different? (I suspect they would be different for each instance).
Now, if I bundle the three PIPs into one collaboration (e.g. one BPSS), what happens now? You might be able to use the same conversation id. But, there is a constraint: you can only do this if the shipment notices and invoices corresponded to the same business entity/object (for example, the order corresponding to the buyer's purchase order #1234 and the seller's sales order #5678). However, I understand that in many business process the shipment notice and/or the invoice will cover multiple purchase orders. What is the conversation id then? Can there more than one conversation id on each message?
/Brian
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, March 14, 2002 6:47 AM
> To: Hayes, Brian
> Cc: ebxml-cppa-negot@lists.oasis-open.org
> 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/m
> sg00025.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/m
> sg00012.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/m
> sg00014.html,
> http://lists.oasis-open.org/archives/ebxml-cppa-negot/200203/m
> sg00016.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