[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
Re-sending due to addressing errors. ************************************************************************************* 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 ************************************************************************************* ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/07/2001 03:17 AM --------------------------- Martin W Sachs 09/07/2001 02:43 AM To: David RR Webber - XMLGlobal <Gnosis_@compuserve.com> cc: christopher ferris <chris.ferris@east.sun.com>, Duane Nickull <duane@xmlglobal.com>, ebxml-msg@oasis-open.org, ebxml-cppa@oasis-open.org, ebtwg@lists.ebtwg.org, Arvola Chan <arvola@tibco.com> From: Martin W Sachs/Watson/IBM@IBMUS Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment (Document link: Martin W. Sachs) David, OK - each of us has been trying to tell the other the same thing. I think that we are converged on that. Regarding "you do need a TRP configuration extension to the CPP": You are absolutely right (almost). Each party has to set up LOCAL configuration information for the Message Service. That can easily be expressed as another XML document. We (IBM) did this in our internal proof of concept prototype of the middleware. The "almost" is this: I would not want to call this local configuration document an "extension to the CPP" because that information is internal to each party. It may or may not have to be tailored for each CPP. Some of it is actually an extension to the BPSS instance document. For example, part of this local information has to map the service and action names in the BPSS instance documents to local method calls or equivalent. This part of the configuration information is probably needed for each BPSS instance document but probably not for each CPP. 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 ************************************************************************************* David RR Webber - XMLGlobal <Gnosis_@compuserve.com>@compuserve.com> on 09/06/2001 09:07:15 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: christopher ferris <chris.ferris@east.sun.com>, Duane Nickull <duane@xmlglobal.com>, ebxml-msg@oasis-open.org, ebxml-cppa@oasis-open.org, ebtwg@lists.ebtwg.org, Arvola Chan <arvola@tibco.com> Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment Marty, This is exactly what I've been trying to tell you all along! Notice - the registry allows you to search on CPPs to discover potential partners who can do the business process you want. Therefore - if those people have not configured their CPP correctly - they lose. Anyway - the bottom line is the CPP can do all this already - and therefore - no need to kludge something into the TRP header. What I have discovered however at implementation is that you do need a TRP configuration extension to the CPP - that simply describes your OWN local system setup, ports, protocols, addresses, but this only so that the TRP software library itself can do its thing correctly. DW. ======================================================= Message text written by Martin W Sachs > Let me try again. A CPP can contain multiple sets of capabilities if its owner chooses to describe all of its capabilities and all of the collaboration protocols it supports. Formation of the CPA consists of putting the two trading partners' CPPs together and picking out the common elements that go with the one collaboration protocol that they want to perform. If each party simply mechanically installed the other's CPP, there is no guarantee that the two systems would know how to behave toward each other. Of course a human being could read the other party's CPP and figure out what information it has to install. That gets back to my original point. If two parties choose to install copies of an incomplete CPA, the need to talk together and figure out what missing information to fill in before they can do business. For simple cases, one of the parties can prepare a CPA template and send it to the other party along with the BPSS instance document. They can then exchange whatever information is missing (e.g. endpoint addresses) and fill that in manually. If more than one or two items need to be filled in, they might as well use tools to automatically generate a complete CPA from their CPPs and then install copies of it. Regards, Marty<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC