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<