[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,
I hope that Arvola will provide a response, especially regarding the PIP
examples.
It is up to the designer of the business process to define the conversation
boundaries and write code to indicate to the MSH across its upper API when
a conversation begins or ends. I would expect that the middleware would
generate a unique conversation ID when a conversation begins and pass that
to the MSH (return it to the application to use with subsequent messages
within the conversation). It is up to the designer of the business process
to define the conversations boundaries such that there is no confusion
about what information goes where at the application level.
I believe (Arvola, please correct me if necessary) that RosettaNet is
providing a separate BPSS instance for each PIP.
The MSG spec provides for only a single conversationId. If a business
process handles multiple purchase orders in a single shipment notice, it
can still have a single conversation, but then, it is up to the application
to further route things by purchase order. To me, it would make more sense
not to bundle the PIPs if that gets into the complexity that you describe.
In general, an application may choose to ignore the value of the
conversation but then it has to do a lot of things that
application-independent middleware could have done for it if it had made
use of the conversation.
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: Martin W Sachs/Watson/IBM@IBMUS
rceone.com> cc: ebxml-cppa-negot@lists.oasis-open.org
Subject: RE: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPP
03/14/2002 02:05 A
PM
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