OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-msg] RE: The Return Path Problem



If any company wants to coordinate the assignment of action and service
names to applications and design its mail room to understand all of that,
nothing in ebXML can stop them.  If you know anyone who has ever done that
over a really large company with physical locations all over the globe, ask
them their experience.  Or just ask a large company that has tried to
deploy Lotus Notes company wide, what their experience has been.

The URL gets you through the network to the destination MSH.  It is a
simple and well understood technique and does not require coordinating
service and action names across the entire company.

For asynchronous messaging, ebXML does not stand in the way of using
different paths for requests and responses.  You just sent up the two
parties' delivery channels accordingly.  We are already talking about
specifying separate delivery channels for signals and for MSH to MSH
messages, so there again, there is nothing to prevent configuring different
paths for the two directions.

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 09:35:58 PM

To:    "'Doug Bunting'" <dougb62@yahoo.com>, ebxml-msg@lists.oasis-open.org
cc:
Subject:    RE: [ebxml-msg] RE: The Return Path Problem





Doug.

>>>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.<<<

I think with the current spec we are already locked into a single method
and that is that error messages, delivery messages, etc *have* to be sent
back using the same path as the original method was sent. With the current
spec Use Case 3 just does not work ! If it can be made to work can someone
please explain to me how?

I am also not trying to lock us into a particular proposal. I am only
suggesting that we include information from the sending service in a
message that is sent that is included in the message that is returned so
that it **may** be used for routing purposes when sending a response. I am
not suggesting that this information *must* be used for routing.

On the other hand I beleive that Marty is suggesting that *all* routing
*has* to be done using the URL and nothing but the URL which, as far as I
can see is a single method.

A few more comments below.

David

-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Monday, November 12, 2001 5:10 PM
To: ebxml-msg@lists.oasis-open.org
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.
<db>I agree. But with the current spec only works if it is sent directly
back to the sending MSH. The current spec does not work if it goes via an
intermediary.</db>

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.
<db>I agree this works.</db>
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.
<db>So what's the point in sending an error if a message is sent
unreliably. Should we change the spec to remove the need.</db>

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.
<db>I disagree. There is a valid usecase where you subcontract to an
outside hub the delivery of messages so that you do not have to maintain
your own directories. I am not trying to force this method of working, I am
trying to allow it to happen.</db>

The main point is that these are fringe use cases and the specification
provides MSH implementations and applications with ways to address them.
<db>Gartner doesn't think so. They said in a recent report ...

"Enterprises that rely on point-to-point solutions,whether from a technical
or a business standpoint, will fail to integrate systems and processes
effectively with more than 25 percent of their business partners (0.8
probability)"

... does this mean that a solution based on "point-to-point" MSHs will
ultimately fail?
</db>

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>


----------------------------------------------------------------
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