David,
Some replies below, "MWS:"
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:49:42 PM
To: Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David"
<david.burdett@commerceone.com>
cc: "Burdett, David" <david.burdett@commerceone.com>, "'Miller, Robert
(GXS)'" <Robert.Miller@gxs.ge.com>, "'ebXML Messaging (E-mail)'"
<ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg] RE: The Return Path Problem
Marty
You said ...
>>>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
messageheader then get it to the software entry point associated with the
destination MSH.<<<
I think you are implying that you **must not** use the Service and Action
to work out the URL of the endpoint. This means that an intermediary, such
as the mailroom MSH, cannot do any logical routing and that the original
sender of a message must know the physical address (aka URL) of the final
application that is to receive a message they want to send.
MWS: That's absolutely correct. The sender gets the physical address from
the CPA.
In turn this means that whenever you change the internal URL for an
application you have to inform everyone who might send you a message which
is a huge (and my view unnecessary) overhead.
MWS: That's no different from anything else in the CPA. It does
discourage people from unnecessarily reconfiguring their networks. Aside
from that a mailroom function could certainly include a "mail forwarding"
function in which if it receives a message directed to a URL that has been
changed, it substitutes the new URL before forwarding the message. This is
no different than the forwarding services that the post office and phone
companies already provide and have provided forever.
If this is what you suggest then I don't think intermediaries can provide
any value add at all from a routing perspective with the standard version
of the spec.
MWS: That's why some people argue that if it is worth having an
intermediary, it must have something to do beyond being a passive
forwarder.
MWS: But the mailroom intermediary can provide the address forwarding
function that I described above.
I think that you should be able to (but not have to) do routing of messages
based on the "PartyId, Service and Action" and map these, either using a
CPA or by table/database look-up to the URL to which the message should be
sent. Is there a problem with this that I don't see?
MWS: There are two problems that you are not seeing. One is that PartyId,
service, and action are not network functions; they only identify the
software to process the message. The URL provides the routing across the
network (inter- and intranet). The second problem that you are not seeing
is that in a large enterprise with many systems scattered, perhaps, all
over the globe, uniqueness of service and action names across the whole
enterprise is something not even to be dreamed of.
David
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, November 12, 2001 1:19 PM
To: Burdett, David
Cc: Burdett, David; 'Miller, Robert (GXS)'; 'ebXML Messaging (E-mail)'
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
>