[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC