[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: PIP IDs
David, I do not think that any illustrative remarks Marty might have provided about how a MSH might store its configuration data forms a basis for showing some technical shortcoming in CPPs or CPAs. The essential point is that the CPP and CPA schemas define standardized patterns to exchange(!) collaboration protocol profiles and agreements. The internal or distributed "storage" of that information (along with other configuration information the MSH will need) is not something we are specifying. So the alternative storage options you raise are irrelevant to the basic purpose of CPPs and CPAs-- which is the specification of standardized ways to exchange information about collaboration protocols. This standardization is hoped to be one step in a continuing effort to make configuration of collaborations more automated and less onerous (less costly) for IS departments. Likewise, while we do in effect insist that there be one "primary key" to a collaboration profile record in its internal representation (whatever that might be) which is, of course, the cpaid, we do not assert that the cpaid is the only primary key, or even that the cpaid is the primary key that any MSH must use as a primary key in its implementation. So I do not believe that your point that we are somehow constraining software implementations is one that has a very substantial foundation. There may be reasons to not be interested in trying to make peer-to-peer collaboration configuration easier. One would be that you are interested in alternative non peer-to-peer architectures based on "nanny intermediaries." That might explain a lack of interest in CPPs and CPAs, though I think even nanny architectures will ultimately benefit from things similar to CPPs and CPAs, such as the descendents of WSDL, or the joint offspring of our pioneer CPPA and WSDL ancestors. But I do not think that your lack of interest in such technologies should be regarded as a technical problem to solve by those of us who are interested in pursuing these technologies. Dale Moberg -----Original Message----- From: Burdett, David Sent: Wed 7/25/2001 9:50 AM To: 'Martin W Sachs' Cc: 'Arvola Chan'; David Fischer; ebXML Msg; Pete Wenzel 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC