[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: PIP IDs
David, Please see my comments below. Cheers, Chris "Burdett, David" wrote: > > Hi Marty ... > > I think there is more of a inconsistency rather than a separation between > the specs. As using the CPA and the Messaging specs together is not easy. This has not been my experience. Quite the contrary I find them quite complementary. If the statement is more along the lines of: "we find it difficult to modify our implementation to leverage a CPA..." then that may be so. However, a blanket statement such as the above needs substantive evidence to back the (fairly inflamatory, IMO) claim. > How about the following as a way forward ... > > 1. The Messaging Specification: > a) Identifies the set of parameters that need to be agreed/shared for MSHs > to interact successfully and that this information can be held: > i) within the ebXML Message Header, or > ii) elsewhere as separately agreed > b) States that the CPAId identifies the values to be used for the > information that needs to be agreed. The specification pretty much does this now, and that IMHO is part of the problem. I think that rather than make continuted efforts to further separate these specs, we should instead be working more closely to align them and to make the use of a CPP/A more compelling. > c) States that **a** method of representing and exchanging the data that > needs to be agreed is defined by the CPPA specification > 3. The CPPA specification describes how those MSH parameters can be recorded > and linked and related to a business process/transaction, etc > > I think that could meet all of our objectives. Does this make sense? I disagree that it meets our objectives. A natural aspect of any b2b exchange is that there is an AGREEMENT between the parties. Even an IMPLICIT agreement is an AGREEMENT. I will grant that without a dynamic negotiation capability, that certain use cases are made more difficult. I DO agree that we should resolve this as part of the work going forward. I also agree that we should look to making the CPP/A as well as the Message Service headers more generally useful by making them more modular. Finally, I also agree that we should be looking to make the Message Service and the CPP/A more useful/applicable in multi-hop environments. I don't think that we've really done this area effectively as we were possibly too focused on getting the point-to-point usage right. > > David > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Sunday, July 29, 2001 6:32 PM > To: Burdett, David > Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel; > ebxml-cppa@lists.oasis-open.org > Subject: RE: PIP IDs > > David, > > I believe that we have achieved the desired separation between the two > specs, all too well. As I pointed out earlier, one of my colleagues who is > doing a prototype implementation of the message service is having a lot of > trouble understanding those aspects related to where the configuration > information comes from. I have asked the CPPA team to include among its > work items, the appendix which is supposed to describe the CPA-related > information used by the message service. Think of it is "How to Interpret > the Message Service Specification when you are using a CPA." > > 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/26/2001 12:05:01 PM > > To: Martin W Sachs/Watson/IBM@IBMUS > cc: "'Arvola Chan'" <arvola@tibco.com>, David Fischer > <david@drummondgroup.com>, ebXML Msg > <ebxml-msg@lists.oasis-open.org>, Pete Wenzel > <Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org > Subject: RE: PIP IDs > > Marty > > You said ... > > >>>The CPPA team is always happy to receive suggestions for improving the > CPP-CPA definition although we would not be too happy to receive a proposal > to simply eliminate it.<<< > > ... that is not my intention. I do think that a CPAs have a role it's just > that I would like to see a clear separation between the ebXML Messaging and > the CPA specs so that they can be used independently of one another. Chris > Ferris described this well in a recent email. > > David > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Wednesday, July 25, 2001 8:51 PM > To: Burdett, David > Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel; > ebxml-cppa@lists.oasis-open.org > Subject: RE: PIP IDs > > David, > > The thrust of the prior discussion was along the lines of "it can't be > done". From that viewpoint, it is sufficient to develop an existence proof > consisting of one way of doing whatever it is (generating the necesary > configuration information). Certainly, there is nothing in the CPP-CPA > specification that precludes RosettaNet or any other industry community > from setting up a small number of prototype CPAs that members of the > community can use. > > The CPPA team is always happy to receive suggestions for improving the > CPP-CPA definition although we would not be too happy to receive a proposal > to simply eliminate it. > > 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/25/2001 12:50:31 PM > > To: Martin W Sachs/Watson/IBM@IBMUS > cc: "'Arvola Chan'" <arvola@tibco.com>, David Fischer > <david@drummondgroup.com>, ebXML Msg > <ebxml-msg@lists.oasis-open.org>, Pete Wenzel > <Pete.Wenzel@RosettaNet.org> > Subject: RE: PIP IDs > > Marty > > Apologies for the delay in responding ... I've been busy elsewhere. > > I agree with everything you say about how databases work and how they > **could** be used to solve the problem. It's just that you are > pre-supposing > a particular internal design for a solution when there are other > alternatives. I also disagree that the information **has** to be entered > into each partners system. > > For example, a community of users, e.g. RosettaNet could define a set of > three or four standard "agreements" that everyone should use for messaging > which exclude partner specific information, e.g. URLs and certificates. The > URL and other information could then be recorded in a registry (UDDI?) > which > a trading partner could look up to determine where to send a message. This > information could also be cached. > > Once the URL was determined, then a message could be sent where the CPAId > referenced one of the "standard" agreements. If the sender of the message > was not previously to the message recipient then they could look up the > information in the registry and decide what to do with the message. > > Marty, I am not saying that your approach is wrong, it's just that there > are > alternaive equally valid approaches which the current definition of the CPA > does not easily support. I think we should support both. Do you agree? > > David > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Friday, July 20, 2001 7:17 AM > To: Burdett, David > Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel > Subject: RE: PIP IDs > > David, > > The usual approach to digesting information from CPAs is to have a database > that has an entry for each CPA. Hence your problem about all the messages > from company A to company B going to the same endpoint doesn't exist. For > each message, the middleware will look at the CPAId and get the right > information out of the database. Of course, once a conversation starts, a > smart system will cache the configuration information for that conversation > so it doesn't have to go back to a disk-based database on every message. > > Database technology has existed for generations that can execute query or > an update against multiple selected rows. > > The rule in your second paragraph is certainly support when all those > messages are associated with the same CPA. For the more general case that > you have in mind, as I said, database technology is well up to it. ...and > don't forget that the changes you have in mind are very infrequent compared > to the frequency of messages in a large, active system. > > Your third paragraph: I disagree. The current perception is that whether > there is a CPA or not, the configuration information has to be entered into > each partner's system and managed there. Some people believe that the CPA, > with suitable tools, is a lot easier to use than the manual methods. > > **************************************************************************** > > ********* > > 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 04:51:03 PM > > To: Martin W Sachs/Watson/IBM@IBMUS > cc: "'Arvola Chan'" <arvola@tibco.com>, David Fischer > <david@drummondgroup.com>, ebXML Msg > <ebxml-msg@lists.oasis-open.org>, Pete Wenzel > <Pete.Wenzel@RosettaNet.org> > Subject: RE: PIP IDs > > Marty > > I agree that a sensible CPA tool should digest the CPA into a table that > allows look up in an efficient manner. The problem is that I am not sure > that it would (or could) actually do it. For example, if you wanted to use > a > very simple routing rule, e.g. "all the messages that company xyz sends to > IBM go to one URL", then the CPA processor would have to **infer** this > rule > from analyzing all the CPAs that define the individual collaborations > between xyz co and IBM. This type of inference processing is both hard to > do > and un-reliable since the inference processor cannot assume that the next > CPA it receives will not follow the rule. Secondly, if you wanted to change > the URL for all these messages then you would have to change all the CPAs > rather than just change the single simple rule. > > To solve this problem, you need to be able to express **directly** a rule > in > its simplest form, (e.g. all messages from xyz co for IBM go to one URL). > However the current CPA structure doesn't support this type of rule > definition (Is that correct?). > > Finally, the current perception of a CPA is, IMO, that it is the **only** > way to specify the information required for ebXML Messaging to work when > clearly there could be more appropriate ways of specifying the information > for some circumstances. Hence my reasons for wanting to be able to use > ebXML > Messaging without CPAs. > > Finally, I do think that CPAs are a good idea especially where you have > point-to-point communication, they're just not the only good idea ;) > > Regards > > David > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Thursday, July 19, 2001 12:48 PM > To: Burdett, David > Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel > Subject: RE: PIP IDs > > 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 > > ------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-cppa-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
begin:vcard n:Ferris;Christopher tel;cell:508-667-0402 tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;;;;; version:2.1 email;internet:chris.ferris@east.sun.com title:Sr. Staff Engineer fn:Christopher Ferris end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC