Jonathan Allen asks if "[anyone would] care to defend the ebXML
position, or challenge [Mike Rawlins'] analysis of ebXML's work and
success so far?"
Okay, I'll step up to the plate. I would probably evaluate ebXML's
"performance" much less harshly than does Rawlins. See ebXML - A
Critical Analysis: ebXML and Interoperability, at
http://www.rawlinsecconsulting.com/. But, of course, I tend to grade
on a curve since everything else out there is pretty mediocre.
I think the ebXML Messaging Services specification probably rates an
"A". Mr. Rawlins would have given it an "F" because of the dearth of
its offerings of protocol bindings, restricted to SMTP and HTTP (like
EDIINT). Since Rawlins infers FTP will also be supported simply because
it is mentioned in the companion CPP/CPA specification, he becomes more
generous and ups the grade to a "C". Well, what else is there besides
SMTP and HTTP (and possibly FTP) that should be garnering so much
attention? Anyway, since ebXML MS is based on SOAP with MIME
Attachments, an ebXML message can be delivered any way that SOAP can.
I predict with a .8 certainty that ebXML Messaging (or something very
much like it) will become the dominant means of packaging, securing,
routing and transporting business payloads - replacing EDIINT AS1 and
AS2 completely. The RosettaNet Implementation Framework (RNIF) will
likely be replaced by ebXML Messaging Services. Besides the promise of
ebXML Messaging Services, what else is there for the robust, reliable
and secure global transport of business payloads? XML Protocol (XMLP)?
It's hard to tell if Rawlins assigned a separate grade to the ebXML
CPP/CPA specification, which presents a novel (to me, at least) approach
to automated Trading Partner Agreement resolution. At the very minimum,
CPP/CPA whould eliminate a lot of onerous manual trading partner
maintenance required today in EDIINT packages. I'd probably toss it an
"A-", with a .8 probability that CPP/CPA (or something substantially
like it) will likely be implemented within the next year or so.
Rawlins throws a "C" at the ebXML Technical Architecture Risk
Assessment. This is sort of a checklist of problems and standards which
are applicable in the ebXML environment. Just compiling all of this
stuff in one place, as ebXML has done, is a formidable effort. I'd be
more generous and give it a "B" - actually no one deserves an "A" unless
he solves the so-far intractable problems of PKI: building a trust
framework (how do I know my TP is really who he says he is?) which
really works for business document transport among SMEs.
Who's going to solve the PKI problem of scalability? Maybe ebXML needs
to build a standards infrastructure for trust and certification of SMEs
(small and medium enterprises) without the need for clumsy paperwork and
in-person presentation, perhaps by extending some of the ideas behind
PGP's (Pretty Good Privacy) informal "web of trust" to the rigidly
hierarchical X.509 world. Only when PKI is completely transparent - and
avoids the need for rapacious and fee-hungry Certificate Authorities -
will it be a success. The student who solves this problem will deserve
an "A".
Rawlins tarred the ebXML Business Process and Core Components efforts
with a composite "D." I'd grade the BP effort a little more generously,
if only because it gives a mechanical XML-based representation of
business processes lacking in RosettaNet today. Is a "C" or
"Incomplete" an acceptable compromise?
I agree with the Ds Rawlins assigned to the ebXML Common Semantics and
Common Vocabulary - which is, I guess, a shorthand way of saying Core
Components specifications nearly failed. And maybe Rawlins is being a
little too generous here. But I don't really much care, because we
still have good old X12 and UN/EDIFACT EDI which we can wrap up as
BASE64 encoded MIME attachments.
William J. Kammerer
Rachel Foerster & Associates, Ltd.
Columbus, US-OH
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
