David,
Some comments below.
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 Fischer" <> on 01/06/2002 05:23:55 PM
To:
Martin W Sachs/Watson/IBM@IBMUS, "Jacques Durand"
<>
cc:
"Arvola Chan" <>, "ebXML Msg"
<>, "Ian. C. Jones \(E-mail\)"
<>
Subject:
RE: [ebxml-msg] Messaging Spec v1.092
I disagree. If the specs were truly loosely coupled then we would not have
discussions concerning discrepancies between the header fields and the CPA.
Errors concerning such discrepancies would be implementation dependant. We
would not worry about aligning Messaging and CPA. We would not have
continual
problems with having to remove fields from the Messaging headers because
they
are already specified in the CPA (in fact, many fields would exist both
places).
MWS: You are missing the point, David. Everything in the CPA is there for
a
reason - to ensure that the two parties are configured compatibly. The
configuration
information has to be in both parties' systems or they cannot communicate.
You cannot
avoid that requirement. The only question is whether the two parties get
together
on a a single configuration description or separately type in the
information
through their own GUIs.
We even voted at the last F2F that there MUST be an agreement in place --
no
allowance for spontaneous eCommerce.
MWS: CPA does not preclude spontaneous eCommerce. Eventually there will be
an
automated composition/negotiation process in place that will allow the
configuration
setup to be fast enough for spontaneous eCommerce. The CPPA team is taking
the
first steps toward this now. Lack of a CPA is what precludes spontaneous
eCommerce because that guarantees that the relationship has to be
configured
manually.
There has been constant discussion that
there MUST be either a CPA or a "virtual CPA", which simply means a
database
containing all the CPA fields and structures even though there may not be
an
actual XML document anywhere. Quotes from the spec to the contrary are
simply
my lack of diligence in removing them since the last F2F.
MWS: See my first comment above. You cannot avoid the runtime database
unless you
think that you can legislate a single software and middleware configuration
that
everyone is required to use on pain of ...
If we could move back to a time when we did allow non-agreement (with or
without
CPA) type eCommerce, then that would remove my objection -- but I don't
think
that is where we are now.
MWS: Non-agreement means non-communication if there are any configuration
variables,
and today there are plenty.
Our original charter was to focus on the SME needs in
eCommerce. I would argue the SME's need something more akin to B2C rather
than
traditional B2B (I don't mean Web based but I do mean spontaneous). My
objection is that our (very good) system is largely a rehash of what has
gone
before (and maybe somewhat of an improvement) but it does NOT adequately
address
the needs of SME's.
MWS: If you want extreme simplicity, SOAP and WSDL have already done it,
so maybe
we should fold up shop and let Web Services take over.
Now, someone else please take the SOAP box ;-).
Regards,
David Fischer
Drummond Group.
