Regarding: "if the intermediary's endpoints are transparently used by the
From Party and
the To Party as their own endpoints in the CPA (i.e., the transport
endpoints in the CPA all contain addresses associated with the
intermediary), then where does the intermediary find the real forwarding
addresses for the From Party and To Party?"
One possibility is that the intermediary acquires the endpoint mapping
information in a way which is outside the scope of the MS specification.
Consider a marketplace whose clients communicate with each other via
endpoint addresses supplied by the marketplace (intermediary). The
messages flow through the marketplace, which does some processing and then
passes them on to the destinations. That marketplace might have a CPA with
each of its clients that supplies the client's real endpoint address (among
other things).
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
*************************************************************************************
Arvola Chan <> on 09/25/2001 03:45:25 PM
To:
christopher ferris <>
cc:
,
Subject: Re: Intermediary support in the 1.1 version of the MSG and CPP/A
specs
Chris:
I agree with you that there will be use cases where a forwarding
intermediary may need to use different transport protocols for inbound and
outbound messages. I believe Dale is assuming that a common CPA will be
used
by the From Party, the To Party, and the intermediary/intermediaries. Maybe
that assumption is too restrictive. Even with such an assumption, it is not
clear to me how it can be made to work. Consider the one intermediary case,
if the intermediary's endpoints are transparently used by the From Party
and
the To Party as their own endpoints in the CPA (i.e., the transport
endpoints in the CPA all contain addresses associated with the
intermediary), then where does the intermediary find the real forwarding
addresses for the From Party and To Party? Clearly, there is extra
configuration information needed by the intermediary that is missing from
the CPA. I also tend to agree with Marty that once you take into
consideration transport level security or if there are multiple
intermediaries, it will be unwieldy to capture all the relevant
configuration information in one CPA.
Has anyone worked out simple examples where a separate CPA is used between
each adjacent pair of MSH nodes? What kind of business processes have to be
used to represent the message forwarding activities? What Service and
Action
elements will be appropriate under the Via element? Is the existing CPP/A
element structure sufficient for this purpose?
Regards,
-Arvola
