[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: message routing
Marty and Prasad, It would be useful to assemble some examples/scenarios/etc that show why conversationId, service, and action (and I would add Role in there to the mix) fail to capture what needs to be asserted about multilateral conversations/flows. I suspect that it is true, but we are saying that there is something not expressible by means of certain semantic elements, so we need to be able to show and agree upon some of what is being left out. There was general agreement for v1.0 that multilateral CPAs were not in scope, but, as I recall, it was more because there wasn't enough time to sort all the issues out than a highly principled omission! I think we are also going to need to revisit terminology, because the tag "Service" has gotten just too tangled up now to use. For example, (referring to the recent PIP threads), talking about the selling service or buying service is semantically like what had previously been called the role in a BP. [I had always thought that the cluster part ("3A" )of a PIP designation was like a service (which I construed as a bundle of "actions"), whereas the "4" in 3A4 was like the Action designator. Returning the POAck was the Action that was the business level Response to the PO (3A4), which was the Request. But that might have been entirely my own picture!] And this is still while thinking about conversations, and before we even get to the web "services" turf! Finally, I think the concern with what information is needed for "routing" to the "application" (and the related process, which is receiving payload(s) from the application and knowing how to send it off), are basically kinds of information that pertain to the "private intranet side of integration" and not to the secure packaged transport or public side of integration. This information is important for the configuration of a MSH on its "application" interfacing sides, but is not clearly something that is needed for a CPA when understood as an agreement on those factors needed to exchange business data interoperably. We have always had a tension in deciding how much of this information to capture in CPPs or a CPA. One place to start in rethinking this issue is what capabilities are being advertized when the "service" , "action" and "role" fields are included in a CPP? For example, for a recipient, are we saying anything more than we can handle the incoming payload so that the output response payload(s) can eventually be made available back to the sender (or to other interested parties in the multilateral case)? Similar issues can be posed about what is being claimed within the CPA context. The point is that the CPA pertains mostly to the contract among/between MSHs, and not to contracts between MSHs and "applications". -----Original Message----- From: Martin W Sachs Sent: Fri 7/20/2001 7:07 AM To: ebxml-cppa@lists.oasis-open.org Cc: Subject: message routing FYI ************************************************************************ ************* 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 ************************************************************************ ************* ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 07/20/2001 10:06 AM --------------------------- Prasad Yendluri <pyendluri@webmethods.com> on 07/19/2001 03:58:18 PM To: Scott Hinkelman/Austin/IBM@IBMUS cc: Arvola Chan <arvola@tibco.com>, Martin W Sachs/Watson/IBM@IBMUS, David Fischer <david@drummondgroup.com>, Burdett David <david.burdett@commerceone.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>, Pete Wenzel <Pete.Wenzel@RosettaNet.org> Subject: Re: PIP IDs Folks, I think I agree with Scott, Arvola and Marty :). Bottomline is, the current model based on the ConversationId, Service and Action is too inadequate to represent an arbitrarily large "conversation", that is potentially "multilateral" (as opposed to the current bilateral) and consists of >= 1 sub bilateral business processes. I think this would be one of important pieces of work for the next version of the MS spec. We need to come up with a more comprehensive, generic, robust and extensible model of a "conversation", that identifies a specific exchange belonging to a "conversation", a business process instance within, the specific action with that process, the originating and receiving parties, the originating and receiving service entities etc. Regards, Prasad -------- Original Message -------- Subject: Re: PIP IDs Date: Thu, 19 Jul 2001 11:41:19 -0700 From: Scott Hinkelman <srh@us.ibm.com> To: Arvola Chan <arvola@tibco.com> CC: Martin W Sachs <mwsachs@us.ibm.com>,David Fischer <david@drummondgroup.com>,Burdett David <david.burdett@commerceone.com>,ebXML Msg <ebxml-msg@lists.oasis-open.org>,Pete Wenzel <Pete.Wenzel@RosettaNet.org> >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. Again, my view on this is to define a Qualified Invocation sequence generically with an arbitrary number of tags, and drop the tag names "Service" and "Action". Just as ebXML Message Service defines a SOAP+Attachments Profile, RosettaNet would define an ebXML Message Service Profile, which would contain mapping to its PIP,etc,etc, (its invocation qualification). Scott Hinkelman, Senior Software Engineer XML Industry Enablement IBM e-business Standards Strategy 512-823-8097 (TL 793-8097) (Cell: 512-940-0519) srh@us.ibm.com, Fax: 512-838-1074 Arvola Chan <arvola@tibco.com> on 07/19/2001 09:03:32 AM To: Martin W Sachs/Watson/IBM@IBMUS, David Fischer <david@drummondgroup.com> cc: Burdett David <david.burdett@commerceone.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>, Pete Wenzel <Pete.Wenzel@RosettaNet.org> 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-cppa-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC