[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: message routing
David, "Invoices greater than a certain value are routed to one location and less than that value to another." This is definitely an application matter. It is highly application dependent and not something that the message service or other component of middleware can accomplish without digging into the payload and understanding the application semantics. However, the CPPA and BP team have to look at this use case if it is a realistic one. It is not clear to me that the CPPA endpoint definitions allow this case. Nor is it clear to me that the BPSS covers this case since, as I understand it, the business transaction can have only one response message and has no means of specifying alternative delivery channels for the same message. 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/27/2001 08:21:34 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: Dale Moberg <dmoberg@cyclonecommerce.com>, ebxml-cppa@lists.oasis-open.org Subject: RE: message routing Marty ... >>>Yes [using data in the payload for routing], but to be strenuously avoided (see my previous posting).<<< I totally agree, but the use case I had in mind would be Invoices greater than a certain value are routed to one location and less than that value to another. It's weird and you could argue it's an application responsibility but then what customers want to do is sometimes weird. >>>There is nothing in the MSG spec that gives permission to use refToMessageId in appication-level messages at all. In order to use refToMessage ID to assist routing of application-level responses, the specification needs to state that in a reply message, refToMessageId contains the message Id of the message that is being replied to.<<< Hmmm! The spec says RefToMessageId ... "MUST contain the MessageId value of an earlier ebXML Message to which this message relates". My interpretation was that this allowed (but didn't restrict) the message to referencing an earlier message that is being replied to. I think this is another point that needs clarification in version 1.1 ... >>>it isn't clear that the Role element in the message service spec is directly related to authorized role in the BPSS spec since it seems to be tied into packaging<<< The role element in the Manifest element IS only related to packaging. The only other reference to role in the spec is lines 762-4 which say ... "Note: In the context of an ebXML business process model, an action equates to the lowest possible role based activity in the [ebBPSS] (requesting or responding role) and a service is a set of related actions for an authorized role within a party." This is making reference to the Authorized role. David -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Wednesday, July 25, 2001 9:30 PM To: Burdett, David Cc: Dale Moberg; ebxml-cppa@lists.oasis-open.org Subject: RE: message routing My replies further embedded below 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 03:55:34 PM To: Martin W Sachs/Watson/IBM@IBMUS, Dale Moberg <dmoberg@cyclonecommerce.com> cc: ebxml-cppa@lists.oasis-open.org Subject: RE: message routing Marty See comments inline. David -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Friday, July 20, 2001 11:41 AM To: Dale Moberg Cc: ebxml-cppa@lists.oasis-open.org Subject: RE: message routing Dale, First, I would like to separate routing from multiparty. ROUTING The routing issues exist at the message service handlers at the From and To party. It has become clear that single conversationId, Service, and Action elements are not necessarily sufficient >>>I agree. You also might need to include: 1. The business process that the message is part of MWS: Yes, that's an additional level in the hierarchy that Arvola is looking for. 2. Anything specifically agreed in the CPA MWS: Yes, if we can identify additional entities. 3. Data included in the payload (not ideal but sometimes necessary!) MWS: Yes, but to be strenuously avoided (see my previous posting). Looking into the payload is forced on a system when the message header doesn't contain the right elements. In the tpaML OBI prototype we had to dig the purchase order number out of the payload because there was no standardized header that included a conversation ID. The ebXML message service is supposed to enable us to avoid doing things like that by including the right generalized elements in the header. <<< and that refToMessageId is not precisely enough defined in the message service spec at this time to be able to rely on it as a routing element. >>>I don't understand why. Can you explain?<<< MWS: There is nothing in the MSG spec that gives permission to use refToMessageId in appication-level messages at all. In order to use refToMessage ID to assist routing of application-level responses, the specification needs to state that in a reply message, refToMessageId contains the message Id of the message that is being replied to. CPAId is also an element in the routing matter. Role should also be useful but it isn't clear that the Role element in the message service spec is directly related to authorized role in the BPSS spec since it seems to be tied into packaging. There have also been suggestions that 2 levels of service and action are not necessarily sufficient although I am not sure that the use of conversationId and CPAId were taken into account. The routing subject needs a lot more attention. >>>Agreed<<< Regarding your fourth paragraph. I definitely agree that the routing issues are on the private side (between MSH and application) but there is also the question of each party understanding what routing information it has to place in the message header to enable correct routing to take place at the destination. That does have CPA implications in that something may have to appear in the CPA to enable each party to understand the other party's needs. >>>There certainly has to be agreement between the parties on what data goes in the header. I also agree that this information "could" go in the CPA. However this suggests that at the extreme, each company is going to sit down with every other company they do business with to work out what this data will be. I don't think this scales. MWS: Of course it doesn't scale. Our teams are supposed to be defining a messaging service that contains sufficient routing elements to cover any application structure we can think of. Once two parties agree on which BPSS instance document describes their collaborative process, the routing elements are defined in that document and no further agreement is needed. We thought that service and action are sufficient but that seems to be not the case and we have to work on ways of generalizing from the two levels to more than two. As long as all the levels are in the BPSS instance document, the routing agreement is implicit and the installation tools do the rest. A more likely approach would be for companies to agree to define the headers according to some community standard (e.g. RosettaNet) which makes the addition of new links to new parties much easier to do. If this happens, then the need for bespoke definitions to go in the headers of messages is significantly reduced. If it is needed, then there are extension mechanisms in the ebXML Messaging Service spec that allow it. It also means that we do not need to define it ... either in the ebXML Messaging Header or the CPA.<<< MWS: As long as you don't care whether members of your community can interoperate with members of mine. ebXML has a goal of universal interoperability. Let's not lose sight of that goal. Perhaps that information is really in the Process Specification document but there are places in the CPA that have to point to the appropriate places in the Process Specification document. MWS: The appropriate places in the CPA already point to the appropriate places in the Proces Specification document. I think that the above paragraph already says it but just to make it perfectly clear regarding your last sentence: The combination of CPA and Process Specification document definitely applies to the contracts between MSHs and applications because that's how Service and Action are defined and tells the middleware what to send to the MSH to put in the Service and Action elements. >>>This is one way of doing it but can be overkill in some circumstances. <<< MWS: Replying here would only reiterate what I said above and in the previous posting. This part is mostly performed by the CPA installation tool >>>If you have one ;)<<< MWS: True. If I have an IBM 650 with only a few thousand words on its random access drum memory and a 1955-style assembler, ebXML won't help me much. For 2001, you want to argue about whether a CPA installation tool that helps both sides reach compatibility is better or worse, simpler or more comple, etc., than a tool into which each party has to type its configuration information and hope that the two match. , of course, when it digests the CPA and builds the control block (database row, perhaps) that manages the information flow related to that CPA. >>>Marty. You seem to be suggesting that companies adopt a specific technology solution. Why?<<< MWS: I am saying that automated tools are a well developed technology and one that doesn't require everyone to use the same one. I am not going to rehash the arguments that a standardized agreement language benefits interoperability for everyone. MULTILATERAL CPAs In IBM Research, we deferred multilateral tpaML when we realized that there were major matters whose solutions would delay the basics. Problems we ran into included: h Multiparty choreography (BPSS may have taken care of this one) Conversation state tracking across parties: To first order, each party needs a view to the message exchanges among all the parties in order to properly track the state of the conversation. >>>This assumes that all the parties need to understand the complete business process. MWS: That is precisely the question. Once you talk about a multiparty CPA, you have to answer all those questions. With tpaML, we decided to practice crawling before trying to walk. ebXML did the same thing for version 1.0. My point here was only that I didn't want the discussion to confuse routing at the destination with multilateral CPAs. They are completely disjoint sets ofproblems. I don't think this is always the case. If I am a bank and make payments when requested. All I need to know is that the request is valid. I don't need to know anything about the business process which is being followed. If the bank does, then we are changing the way business happens now.<<< A has to know about the messages between B and C to understand the current state. It wasn't clear how to do this without introducing yet more messages to exchange state information or if we could simply things by deciding that C does not have to know everything about what A and B are doing. Are there things going on between B and C that A isn't supposed to know about even though there is a CPA among the three of them? Are there things in the CPA that relate to matters between B and C that A shouldn't even see in the CPA? Are there new security issues with more than two parties? We didn't give up on these problems. It was more of a case of crawling before walking before running. So yes, at least in my mind, leaving multiparty CPAs out of scope for version 1 was a matter of not having enough time to work the problem than because of any principle. We have seen the result of Core Components perhaps being too ambitious. 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 **************************************************************************** ********* Dale Moberg <dmoberg@cyclonecommerce.com> on 07/20/2001 11:56:41 AM To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-cppa@lists.oasis-open.org cc: 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 ------------------------------------------------------------------ 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