[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] RE: The Return Path Problem
David, The return path works the same way. The response is sent using the requester's delivery channel which has the correct endpoint URL to get the message to where it is supposed to go. Remember: delivery channel = receive properties. In summary, it's the endpoint URL that gets the message through the network to the mailroom and to the correct place on the enterprises's internal network (final destination MSH). The routing elements in the message header then get it to the software entry point associated with the destination MSH. This approach requires no global (within the enterprise) definitions of service, action, CPAId, or anything else except the endpoint URLs. The mail room doesn't deal with the routing elements in the message header; it just passes the message on according to the URL. The mailroom or any other MSH doesn't stick anything on the end of the endpoint URL. The URL is provided in the CPP and CPA and is designed by the people who understand the configuration of the enterprise's internal network. 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 03:54:22 PM To: Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David" <david.burdett@commerceone.com> cc: "'Miller, Robert (GXS)'" <Robert.Miller@gxs.ge.com>, "Burdett, David" <david.burdett@commerceone.com>, "'ebXML Messaging (E-mail)'" <ebxml-msg@lists.oasis-open.org> Subject: RE: [ebxml-msg] RE: The Return Path Problem Marty In the examples you give, are these PartyIds or are they the URL to which a message is physically sent. I'm assuming the latter. If so, then your suggestion works for the outbound message but I doesn't as far as I can see work for *the return path* as the MSH returning the message does not know which service sent the original message and therefore what it should put on the end of the URL. For example, if the outbound message was as follows ... <MessageHeader> <From><PartyId>XYZinc</PartyId></From> <To><PartyId>ABCco</PartyId></To> <CPAId>ABC-XYZ-CPA</CPAId> <ConversationId>5678</ConversationId <Service>PriceCheck</Service> <Action>PriceCheckResponse</Action> <MessageData> <MessageId>56723</MessageId> <RefToMessageId>79465</RefToMessageId> ... </MessageData> ... </MessageHeader> ... then the only way the MSH sending the response to this message can know what to put at the end of the URL is from the CPAId and the agreement that was set up previously. This means that you need separate CPAs for, in Use Case 1, the Buyer order Management Service and the Price Query Service. I don't think this is right as why should XYZ Co care which internal service made the request for a Price Check. ... or am I missing something. David -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Monday, November 12, 2001 10:21 AM To: Burdett, David Cc: 'Miller, Robert (GXS)'; Burdett, David; 'ebXML Messaging (E-mail)' Subject: RE: [ebxml-msg] RE: The Return Path Problem The way I read Bob Miller's posting he is suggesting completely separating routing through the network from the PartyIds. He is suggesting using the endpoint URL to do the routing in the standard way. Thus a message might go to http://www.ABCco.com/CustomerService or http://www.ABCco.com/Procurement/CustomerService The domain name gets the message to the mail room and the rest of the segments of the URL get it to its final destination behind the mail room. The enterprise may design the routing however it wishes and express it in the URL. 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 12:47:45 PM To: "'Miller, Robert (GXS)'" <Robert.Miller@gxs.ge.com>, "Burdett, David" <david.burdett@commerceone.com>, "'ebXML Messaging (E-mail)'" <ebxml-msg@lists.oasis-open.org> cc: Subject: RE: [ebxml-msg] RE: The Return Path Problem Bob This effectively what I am suggesting except that I want to make it explicit. The PartyId should identify the "business" or a division of the business. In the real world we would would say,please reply to: Customer Service ABC Co 123 Main St Smallville, CA In this instance the internal department is "Customer Service" and the Party is "ABC Co". Doing it your way we would say, please reply to: Customer Service, ABC Co 123 Main St Smallville, CA Where "Customer Service, ABC Co" is the Party and department combined. Although we could do it the way you suggest and concatenate the two in the spec, this is not the best way to do it if you are using XML where the whole idea is to make the different elements of a data structure explicit. It also causes problems for the recipient. For example, following your suggestion your PartyId might look something like: <From><PartyId>urn:duns:1234567:fromservice:CustService</PartyId></From> The recipient now has a problem that they don't which part of the PartyId identifies the business and which the service unless we specify the standard in the spec. This means that they might not even be able to recognize the sending Party. I think it would be much easier if we had: <From><PartyId>urn:duns:1234567</PartyId><Service>CustService</Service></Fro m> In this case the PartyID represents the business and the "From Service" is identified separately. So really I am agreeing with you except that I think we should make the information explicit rather than buried in the PartyId. David -----Original Message----- From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com] Sent: Monday, November 12, 2001 6:24 AM To: Burdett, David; 'ebXML Messaging (E-mail)' Subject: RE: [ebxml-msg] RE: The Return Path Problem Good People, In the EDI world, we simply use multiple from party addresses. For example, we might use a DUNS number, in which the high order part of the number has been assigned to our compnay, and the low order portion is internally assigned. Seems to me that life gets even easier in the Internet world. We're all familiar with the EMail 'mailroom'. It's the name that follows the "@" symbol. The internal address is the part that preceeds the "@" symbol. We're also familiar with subaddesses in the WWW. The mailroom address preceeds the '/', and the subaddresses follow the first '/'/ Why isn't the obvious solution being considered? I'm confused. Cheers, Bob Miller -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Friday, November 09, 2001 7:31 PM To: 'ebXML Messaging (E-mail)' Subject: [ebxml-msg] RE: The Return Path Problem I forgot the attachment ... ;( David <<The Return Path Problem.pdf>> > -----Original Message----- > From: Burdett, David > Sent: Friday, November 09, 2001 5:28 PM > To: ebXML Messaging (E-mail) > Subject: The Return Path Problem > > Folks > > Here's a PDF that describes three use cases that illustrate the return > path problem that is on the agenda for next week's F2F. Two of the use > cases are from the meeting at SAP in October which we never got round to > discussing the third is new. > > I also suggest some solutions. Note that these are suggestions and I am > open to alternatives. > > If anyone has any comments before the meeting then ... ;) > > Regards > > David > > Product Manager, xCBL, XML Standards > Solution Strategy, Commerce One > 4400 Rosewood Drive, Pleasanton, CA 94588, USA > Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704 > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC