[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: PIP IDs
That's the way I see it as well. Cheers, Chris Martin W Sachs wrote: > > David, > > Please forgive my repetition, but... > > Your two points: > > look up the CPA from the CPA ID and route the message to the endpoint > identified, or > > look up the Party, Service and Action in a table to identify where to > send the message to. > > are really one and the same since any sensible CPA tool will digest the CPA > into a table that allows looking up the routing information in the most > efficient manner. The only difference between them is where the table > comes from. > > 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 > ************************************************************************************* > > "Burdett, David" <david.burdett@commerceone.com> on 07/19/2001 03:17:41 PM > > To: "'Arvola Chan'" <arvola@tibco.com>, Martin W Sachs/Watson/IBM@IBMUS, > David Fischer <david@drummondgroup.com> > cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>, Pete Wenzel > <Pete.Wenzel@RosettaNet.org> > Subject: RE: PIP IDs > > Thanks Arvola !! You have saved me from writing an email. I absolutely > concur with what you say ... you can have one "service" > supporting multiple different business transactions. If we do this it also > means that we can have one conversation involving multiple different > business transactions, e.g. a 3A4 (Create Purchase Order) followed by a > 3A8 (Change Purchase Order) where the change purchase order was for the > order created by the create purchase order. > > Another use case is where you can have the same service used in multiple > different collaborations for example consider the following two > collaborations: > Example 1, Invoice Payment: > 1. BT1 - Present Invoice > 2. BT2 - Make Payment > > Example 2, Pay Refund: > 1. BT1 - Request Refund > 2. BT2 - Make Payment > > Both of these involve making a payment which, in Business Transaction > terms, would be carried out the same way. > > Where I think it gets really critical to separate the two is when you want > to route messages. If Party, Service and Action are always the same, > irrespective of the business process in which they are being used then you > can use these three fields for routing purposes in a consistent way. > > On reflection this I think is one of the issues I have with always > requiring a CPA as defined in the CPA/CPP spec as you can actually quite > reasonably do routing in two different ways: > > look up the CPA from the CPA ID and route the message to the endpoint > identified, or > look up the Party, Service and Action in a table to identify where to > send the message to. > > The former allows you to vary the endpoint very flexibly and alter where > you send a message to depending on the business process you are in, the > latter allows you to have simpler rules but with less flexibility. > > I think both use cases are valid ... and required .. > > David > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Thursday, July 19, 2001 9:04 AM > To: Martin W Sachs; David Fischer > Cc: Burdett, David; ebXML Msg; Pete Wenzel > Subject: Re: PIP IDs > > Marty, > > Up to now, RosettaNet PIPs are either request-response (two-actions) or > notification (one-action) style business processes. Earlier versions of > PIP 3A4 are an exception in the sense that PIP 3A4 covers Create Purchase > Order (request-response), Change Purchase Order (request-response) and > Cancel Purchase Order (request-response) interactions. Recently, PIP 3A4 > has been split into 3A4 (Create Purchase Order), 3A8 (Change Purchase > Order), and 3A9 (Cancel Purchase Order) in order to achieve some degree of > uniformity across PIPs (I believe). Therefore, I think it is reasonable to > equate existing RosettaNet PIPs with BPSS Business Transactions. > > In the RosettaNet message header, there are separate elements to identify > the PIP ID, the PIP action and the Service. Multiple PIPs may be > implemented by the same service, e.g., there may be a Buyer service > implementing PIPs 3A4, 3A8, 3A9 from the buyer perspective, and a Seller > service implementing the same PIPs from the seller perspective. > > I don't think we should equate PIP ID with Service and action with "the > particular business transaction within the PIP". Otherwise, we will not be > able to capture the role information, e.g., the ability to distinguish a > Buyer Service from a Seller Service, and a request action from a response > action. > > From the RosettaNet point of view, it will be desirable if we can have > distinct Service, PIP (equivalently BPSS Business Transaction), and action > elements in the message header. Alternatively, we can use the Service > element to capture role information (e.g., Buyer vs Seller), and use the > Action element to capture the PIP ID. Whether we are dealing with a > request action or a response action will have to be inferred from the > Service element. > > Regards, > -Arvola > > Arvola Chan (arvola@tibco.com) > TIBCO Software (on loan to RosettaNet) > +1-650-846-5046 (US-Pacific) > > ----- Original Message ----- > From: "Martin W Sachs" <mwsachs@us.ibm.com> > To: "David Fischer" <david@drummondgroup.com> > Cc: "Burdett, David" <david.burdett@commerceone.com>; "ebXML Msg" < > ebxml-msg@lists.oasis-open.org> > Sent: Thursday, July 19, 2001 8:07 AM > Subject: Re: PIP IDs > > In my opinion it makes more sense for Service to point to the PIP ID and > action to point to the particular business transaction within the PIP. In > other words one execution of a PIP is a conversation. I believe that some > of the PIPs include multiple business transactions. > > 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 > ************************************************************************************* > > David Fischer <david@drummondgroup.com> on 07/19/2001 10:45:54 AM > > To: "Burdett, David" <david.burdett@commerceone.com> > cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> > Subject: PIP IDs > > David, in the F2F you mentioned the need for a new element to contain > industry specific business process identifiers such as a RosettaNet PIP > identifier. Could this be done with Service/Action where the Service would > be something like RNet and the Action something like PIP3A1 (Request > Quote)? > > <eb:Service>urn:services:RNet</eb:Service> > <eb:Action>PIP3A1</eb:Action> > > Regards, > > David Fischer > Drummond Group. > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC