RE: Use cases for IM's

["Burdett, David" <david.burdett@commerceone.com>]

Marty

See comments inline below.

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, September 14, 2001 6:35 AM
To: Burdett, David
Subject: RE: Use cases for IM's



This use case is fine as long as B and C1 can recognize all of the "real"
destinations' endpoint addresses.  There may be a teeny problem if the
mailroom MSH is forwarding over an internet or intranet.  
<db>I think this will be very common particulary within a business.</db>

Since the
endpoint addresses include the IP address or equivalent domain name, IP has
to be able to send the messages from A first to B/C1 and later from B/C1 to
the real endpoint addresses. 
<db>Correct</db>

An obvious solution is to include B/C1's own
IP address in the To addresses used by A and have the mailroom forward to
the real IP addresses of the To parties. 
<db>This would work, although all B needs to tell A is which IP address to
use for sending its messages to. Whether this is ebxml.c1.com or ebxml.b.com
should not make any difference. B could use a CPA to inform A of this
information.</db>

Then the mailroom is not totally transparent to A.
<db>I don't see why all A is doing is sending a message to a URL. It should
not matter to A whether this is the URL of the MSH that is directly in front
of the App, a mailroom MSH run by B, or a mailroom MSH run by someone else.
It's just a URL.</db>

In addition, swapping IP addresses means that the B/C1
MSH is doing something outside the scope of the MSH, 
<db>I think you are saying that a MSH is **strictly** point-to-point and
anything outside of this scope is not part of a MSH but something different.
Whether it is in or outside the scope of a MSH, it needs to be within the
scope of ebXML MS.</db>
so in fact it has its
own business process and cannot be treated as a dumb store and forward node
for RM purposes.
<db>This "business process" is no different to the "business process" that
US Postal service does to deliver your mail. The postal delivery services is
not normally considered part of the "real" business process, e.g. placing a
purchase order. The Postal Service function is also very much part of
"transport, routing and packaging" and therefore wihtin our scope.</db>

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 09/13/2001 12:07:35 PM

To:   "'Dan Weinreb'" <dlw@exceloncorp.com>
cc:   ebxml-msg@lists.oasis-open.org
Subject:  RE: Use cases for IM's



Dan

You raise a valid question as, I admit I have been one of the strongest
advocates for "intermediary support". However I don't think it is a
requirement that just applies to the likes of Commerce One and Ariba.

The very common use case which I think will apply to many businesses is
illustrated by the following diagram originally suggested by Chris Ferris:


   A -------------- BM ------ B1 ------- B
  MSH              MSH       MSH        APP1
                    |
                     -------- B2 ------- B
                             MSH        APP2

In this "point-to-point" use case there are two partys involved, Party A
and
Party B. Party B runs within their systems: the BM, B1 and B2 MSHs as well
as B's APPs 1 and 2. The BM MSH is a "mailroom" MSH in that it forwards
messages to another MSH (either B1 or B2) which then hands the message off
to the application (either APP1 or APP2). The BM MSH does not "process" the
message in a business sense as it does not look at the payload.

In this example the BM MSH is an intermediary, yet, I would argue, A should
not need to know that it is actually dealing with an intermediary. It
should
be transparent.

This use case is why I think many of us will need to support
intermediaries.

Now for Commerce One. ONE of the (many) uses for ebXML that Commerce One
has
is illustrated by the diagram below:

   A -------------- C1 ------ D -------- D
  MSH              MSH       MSH        APP
                    |
                     -------- E -------- E
                             MSH        APP

Note that, as far as use of MSH's are concerned, this is IDENTICAL to the
previous diagram except that Commerce One is providing the mailroom
function
rather than it being inside party B. Also links are made to many different
parties (i.e. D & E), not just one (i.e. B).

So, yes Commerce One NEEDS intermediary support, but then I think many of
us
will which is why it is important and needs to be included in a transparent
way.

Regards

David

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Wednesday, September 12, 2001 10:20 PM
To: Burdett, David
Cc: ebxml-msg@lists.oasis-open.org
Subject: Use cases for IM's


In today's conference call, I believe I heard someone say that support
for IM's was of particularly high priority because they are needed
by CommerceOne.  Earlier email has cited CommerceOne and Ariba as
examples of IM's:

   processing intermediaries. If the intermediaries were merely
   and exclusively routing intermediaries, then that might be one
   thing. However, I don't believe for a minute that C1 and Ariba
   consider themselves as mere routers.

Do you agree that a compelling reason for providing IM functionality
is to meet the needs of compannies such as CommerceOne and Ariba?

I confess that I do not have as good an understanding as ought to of
how business processes would work in situations where a company such
as CommerceOne or Ariba (their customers, actually, if I am getting
this right) would serve as an IM.  If you agree that this is a
motivating case for IM's, I wonder if you could explain how IM's
fit into this picture.

As I understand it, these companies make software that can be used to
establish a "marketplace", in which, say, buyers and sellers, rather
than interoperating in a direct point-by-point fashion, interoperate
with the marketplace instead.  (Or maybe they do some things through
the marketplace and other things directly?)

But if I were using a marketplace, it seems to me that this would best
be modelled as a business process whose parties were me and the
marketplace.  I don't think I understand when there would be a
scenario in which party X is engaging in a business process with party
Y (e.g. X sends a request to Y and Y replies to X, or Y notifies X, or
Y solicits X and X replies to Y), but the messages between X and Y are
sent indirectly through the "marketplace" implementation acting as an
IM at the ebXML MS layer of abstraction.  Why is that the right model?

Thank you.
-- Dan

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>