[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] RE: The Return Path Problem
Marty, You hit a very important point that is missing from David's paper and the subsequent discussion: Content-based routing requires function that understands the content. That's usually viewed as application function, not message routing. In the MS specification, we're designing a message routing infrastructure and have explicitly avoided defining particular routing paradigms. David is proposing one routing paradigm, others are free to choose something different. However, going further with David's proposal locks us into a single method. The ebXML-MSH specification touches on the return path or repeating an outbound path in a few ways: 1) Message Status query: If an ebXML-MSH has a name, it's the URL as you have described earlier. Whether or not that name gets you to a particular software stack is immaterial as long as it appears to operate in that fashion. To Dan's earlier questions about the Message Status query, internal routing based on service, action or any other parameters besides the PartyId and given URL MUST NOT prevent the Message Status query from operating. OK, Message Status is somewhat optional so the internal routing can be as haphazard as you please... 2) Errors, Acknowledgements, et cetera: Must go back to the originating MSH. This is identified in the CPA though you've mentioned some problems with the current CPA specification with respect to having different error paths for different requests (really, multiple return paths per request). We've also identified the service and action that must be used when sending errors or acknowledgements alone. 3) Business responses: This is the big one described in David's first use case. It's completely up to the designers of the integration between companies to decide the services and actions used to identify each part of their exchange. The information necessary to create a business response must be in the CPA. Besides that, it's up to the application levels at the responder (To party of the original message) to craft the entire response, including making a choice about the service and action. David, I'd probably build an MSH that recognises message identifiers in the RefToMessageId and associates them with internal systems (the originating MSH) were I to build a mailroom as complicated as outlined in the proposal. It's a single value and this implementation doesn't require any external description. I don't buy the argument that this requires storage of every MessageId ever sent -- if you send something unreliably, you don't care (that much) about errors. I also don't buy arguments that involve different outbound and return paths that aren't identified in the CPA beforehand. ABC Co. isn't likely to tell eHubsRUs much about it's internal routing and will implement a mailroom if its situation is as complicated as you describe. The main point is that these are fringe use cases and the specification provides MSH implementations and applications with ways to address them. later, doug ----- Original Message ----- From: "Martin W Sachs" <mwsachs@us.ibm.com> To: "Burdett, David" <david.burdett@commerceone.com> Cc: "'Dan Weinreb'" <dlw@exceloncorp.com>; "Burdett, David" <david.burdett@commerceone.com>; <ebxml-msg@lists.oasis-open.org> Sent: Monday, 12 November 2001 14:53 Subject: RE: [ebxml-msg] RE: The Return Path Problem David, If you do some thinking about all the things that might differ between applications, you might reconsider wanting a CPA to cover an entire enterprise. There is nothing to stop a CPA between two parties from including more than one BPSS description but it probably wouldn't be too many. Content-based routing requires function that understands the content. That's usually viewed as application function, not message routing. 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 11/12/2001 04:59:39 PM To: "'Dan Weinreb'" <dlw@exceloncorp.com>, "Burdett, David" <david.burdett@commerceone.com> cc: ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] RE: The Return Path Problem Dan I agree with your definition of a "Party", and yes I assume that there is only one MSH within a party that implements a Service and Action. I also agree that we need to be more explicit about what is (or is not) a Party and MSH. However I don't think that limiting a Party to one MSH Service and Action is necessarily a problem as: 1. A Party can represent a division of a company (as in DUNS+4) 2. If you need more than one MSH for a Service and Action within a company, then you do content based routing where some other data (perhaps in the payload) is ued to do the second level routing. I also think that a CPA should be between businesses and not between applications as the maintenance level required by the keeping CPAs between individual applications is too high. What I think Marty's suggestion implies would mean you would have to update your CPA with a business if you wanted to do a query for a new reason. I also agree that Service and Action are "what" type information and that we need the "how". It's just that I think you should be able to dervice the "how" dynamically from the "what" rather than just ignore the "what" for routing purposes. Regards David -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Monday, November 12, 2001 1:41 PM To: david.burdett@commerceone.com Cc: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] RE: The Return Path Problem In my mind, the topic of your paper is closely related to the questions I've been asking about "how do you name an MSH" or "how do you name a party". I think there has been some confusion about what we mean by a "party": is "ABC Co" is a party, or is "Order Management MSH" a party? Marty seemed to be suggesting the latter, to which I replied that then a "partyId" would not be an identifier of a "party". It looks to me like you're assuming: -- ABC Co. is one "party". Order Management MSH is not a "party". -- A "party" is identified by a "partyId" (i.e. each partyId denotes one specific "party". -- There is one CPA, between the "parties", so there isn't a separate CPA for the different paths shown in your figure 1-1. In your paper, you suggest using the Service and Action fields in order to figure out how to route the message. It seems to me that there is a tacit assumption behind this suggestion, which I think needs to be made explicit. It assumes that you never have two distinct MSH's within one "party" that both implement the same Service/Action. Is this really a safe assumption? If a "party" might be a large corporation, the corporation could have many divisions, each of which provides the service "Purchasing" with the action "Submit PO". It seems to me that Service & Action are an assertion about *what* to do, not *who* is doing it. For routing, we want to use "who-like" information. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC