ebxml-msg — archive

Re: Intermediary support in the 1.1 version of the MSG and CPP/A specs

From: System
To: [email protected]
Date: Tue, 25 Sep 2001 17:38:00 -0000

Regarding Arvola's second paragraph: I believe that the existing content of the CPA is sufficient for expressing the interaction between each endpoint and the intermediary. A separate CPA would express whatever configuration information has to be known between the two endpoints (marketplace clients); possibly, this CPA would be only a subset of the CPA definition and might require redefining some elements/attributes to have minOccurs="0". I believe, but am less certain, that a normal CPA would also suffice to interconnect two adjacent intermediaries. For the example that I gave in the previous posting, I don't believe that it would be necessary for those CPAs to reference each other. I am, of course, talking about a use case in which the intermediary is not "hidden". 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 <[email protected]> on 09/25/2001 03:45:25 PM To: christopher ferris <[email protected]> cc: [email protected], [email protected] 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