[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Use cases for IM's
Marty
I agree that the functions are outside the scope of the current MSH. What I
am describing is some of the uses to which the current ebXML MS spec could
be used. I also agree that there are no "dumb" intermediary nodes as they
must make some decisions on where to send a message to. However, that is
all. They should also only look at the data in the header to determine what
to send the message to next. This is just like a Post Office, e.g. the US
Postal Service. They look at the address on the envelope and decide where to
send it next. They do not look at the content of the letter.
I think that allowing this "postal service" functionality to work is
definitely within our scope. We also need to allow "hand delivery" of
messages as well.
David
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, September 14, 2001 6:47 AM
To: Burdett, David
Cc: 'Dan Weinreb'; ebxml-msg@lists.oasis-open.org
Subject: RE: Use cases for IM's
David,
Excuse me if I am repeating myself but most, if not all, of the functions
you list below are well out of the scope of the current MSH specification.
That mailroom is a node with two MSHs and some amout of higher level
processing in between. To move on, we must achieve consensus that there
are no dumb intermediate nodes and no such thing as an intermediary with
only one MSH. Yes, code might be shared between the two MSHs but from the
view point of architecture, data structures, etc. there are two MSHs in
there.
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 03:56:53 PM
To: "'Dan Weinreb'" <dlw@exceloncorp.com>
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: Use cases for IM's
Dan
You asked ...
>>>But then why does BM [the mailroom MSH] have to be an MSH at all?<<<
Some reasons include (there are probably more):
1. The BM MSH can keep the URLs of all external Partys which B does
business
with (e.g. A). This keeps all the look ups in one place which makes it
easier to maintain. Otherwise each application would have to do it on its
own.
2. It means that external businesses (e.g. Party A) can be given a single
URL to use to send messages for B, as the Mailroom MSH will forward it to
the correct application. This means that ...
3. If B re-organizes its systems internally and wants to move an
application
to a different URL, then it does not need to notify the external Parties it
does business with as the external URL does not change.
4. Some of the links to an application may not use an ebXML front end at
all, for example ...
A -------------- BM ------ B1 ------- B
MSH MSH MSH APP1
|
|-------- B2 ------- B
| MSH APP2
|
----- Inteface ---- B
App APP3
In this case, B's mailroom MSH can allow the application (APP3) to exchange
messages with the rest of the world using ebXML which it could not do if it
had to use only SMTP. A variation of this is ...
5. The link to an application is done in batch, say once a day. However
there is a need to provide an immediater response over HTTP for messages
that are received. With this configuration, B's mailroom MSH can send an
acknowledgement or even a delivery receipt immediately back to the sender
(e.g. A) and later forward the message to the application
... then you said ...
>>>Since it doesn't actually interpret the message, there's no need for it
to know the ebXML MS protocol at all.<<<
Does it NEED to know it, perhaps not. However there is often going to be a
need for some kind of internal routing of a message from one MSH to
another.
You cannot just use a simple communications protocol as it menas the
parties
you do business with will have to be informed all of your updates. Using a
mailroom MSH makes it much easier to do.
... and then you said ...
>>>But if it [Commerce One] is still just passing the messages through
without interpreting them, the same point holds: don't consider it to be an
MSH.<<<
If you accept the benefits of using a mailroom MSH as described above, then
all we are doing is offering to outsource the service (for a fee ;).
David
-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Thursday, September 13, 2001 11:12 AM
To: Burdett, David
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: Use cases for IM's
Date: Thu, 13 Sep 2001 09:07:35 -0700
From: "Burdett, David" <david.burdett@commerceone.com>
The very common use case which I think will apply to many businesses is
illustrated by the following diagram originally suggested by Chris
Ferris:
....
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.
But then why does BM have to be an MSH at all? Instead, why not just
make BM an SMTP store-and-forward mailer, or the equivalent thing
using HTTP? In other words, consider BM to be operating at the
communication layer. Then it will really be invisible. And nobody
will bother to worry about CPA's to which it's a party: it doesn't
have to worry about CPA's at all. After all, you say:
The BM MSH does not "process"
the
message in a business sense as it does not look at the payload.
Since it doesn't actually interpret the message, there's no need for
it to know the ebXML MS protocol at all.
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).
But if it's still just passing the messages through without
interpreting them, the same point holds: don't consider it to be an
MSH.
----------------------------------------------------------------
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