ebxml-msg — archive

RE: Use cases for IM's

From: System
To: [email protected]
Date: Fri, 14 Sep 2001 09:50:00 -0000

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" <[email protected]> on 09/13/2001 03:56:53 PM To: "'Dan Weinreb'" <[email protected]> cc: [email protected] 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