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
