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