Chris,
See my notes below <srh>.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
christopher ferris <chris.ferris@east.sun.com> on 07/31/2001 04:12:58 AM
To: "Burdett, David" <david.burdett@commerceone.com>
cc: Martin W Sachs/Watson/IBM@IBMUS, "'Arvola Chan'" <arvola@tibco.com>,
David Fischer <david@drummondgroup.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>, Pete Wenzel
<Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org
Subject: Re: PIP IDs
David,
Please see my comments below.
Cheers,
Chris
"Burdett, David" wrote:
>
> Hi Marty ...
>
> I think there is more of a inconsistency rather than a separation between
> the specs. As using the CPA and the Messaging specs together is not easy.
This has not been my experience. Quite the contrary I find them
quite complementary. If the statement is more along the lines of:
"we find it difficult to modify our implementation to leverage a CPA..."
then that may be so. However, a blanket statement such as the above
needs substantive evidence to back the (fairly inflamatory, IMO) claim.
<srh> This has not been my experience either. Engine logic is nicely driven
by external an configuration file, which at the software level is what a
CPA
is. However, David's words "not easy" I will interperet to mean as "alot to
buy into", which I would agree to. The CPA is not simple, and there has
been
clear feedback in the Dallas meeting along the lines.
I would add also that a good msh engine design that needs configuration
information would abstract away the detail of the CPA, and allow obtaining
that information from alternate places. For this design reason, I am not
in favor of *explicitly requiring* a CPA.
> How about the following as a way forward ...
>
> 1. The Messaging Specification:
> a) Identifies the set of parameters that need to be agreed/shared for
MSHs
> to interact successfully and that this information can be held:
> i) within the ebXML Message Header, or
> ii) elsewhere as separately agreed
> b) States that the CPAId identifies the values to be used for the
> information that needs to be agreed.
The specification pretty much does this now, and that IMHO is part of the
problem. I think that rather than make continuted efforts to further
separate these specs, we should instead be working more closely
to align them and to make the use of a CPP/A more compelling.
<srh> I agree it should be as *aligned* as possible. That *could* mean some
common structure for fundamental information. That type of approach would
indeed make the CPA more compelling.
> c) States that **a** method of representing and exchanging the data
that
> needs to be agreed is defined by the CPPA specification
> 3. The CPPA specification describes how those MSH parameters can be
recorded
> and linked and related to a business process/transaction, etc
>
> I think that could meet all of our objectives. Does this make sense?
I disagree that it meets our objectives.
A natural aspect of any b2b exchange is that there is an AGREEMENT
between the parties. Even an IMPLICIT agreement is an AGREEMENT.
<srh> I agree.
I will grant that without a dynamic negotiation
capability, that certain use cases are made more difficult. I DO agree
that we should resolve this as part of the work going forward.
I also agree that we should look to making the CPP/A as well as the
Message Service headers more generally useful by making them more modular.
<srh> absolutely.
Finally, I also agree that we should be looking to make the
Message Service and the CPP/A more useful/applicable in multi-hop
environments. I don't think that we've really done this area
effectively as we were possibly too focused on getting the
point-to-point usage right.
>
> David
>
>