A qualification here - some of you may know that Jonathan, William, and I
all know each other and have worked together in X12C. However, this was
*not* a setup!
Before I answer some of William's comments below, let me first clarify that
I wasn't grading *all* of ebXML or even specific specifications. I was
grading ebXML strictly on interoperability as defined in the ebXML
Requirements Specification. This is the primary problem that ebXML was
supposed to solve, so I chose it first. I believe ebXML made other
contributions and addressed other problems, as I will discuss later in the
series. I just don't think it did very well on interoperability.
"William J. Kammerer" wrote <snipped>:
>
> 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.
If I were just grading the messaging services overall, I would rate it a
"B". The main reason that it wouldn't rate an "A" is that it is so
complex. The primary problem that I point out in regard to interoperability
is that ebXML refused to give very much guidance, not to mention a
specification, regarding choosing FTP vs SMTP vs HTTP, etc. These are
incompatible, non-interoperable methods of file transport. As a long time
reader on this list can attest, people do frequently seek guidance on which
to choose. Perhaps a "C" was a bit to harsh, but I gave a "C" instead of a
"B" because in my opinion ebXML consistently placed higher priority on other
quality requirements such as openness than it did on interoperability.
>
> 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.
As I said above, I didn't address CPA/CPP specifically in this article. It
is a very nice piece of work and I'll address it later on. However, based
on the dearth of implementations of the X12 838 (excluding the U.S. Federal
Government), I don't estimate any more than about a .4 probability that it
will see wide spread implementation.
>
> 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.
I didn't grade the Technical Architecture Risk Assessment, I only mentioned
it as a basis for the rating on security. It is a very good document and I
would rate it at least an A-.
>
>
> 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".
I ask the same questions and agree with your assessment.
>
>
> 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 don't assign incompletes since you can never be sure they'll be converted
to complete. I only take snapshots in time. I think what is required for
CEFACT to achieve a "B" on interoperability in continuing the ebXML BP work
is not only a completed methodology and catalogue, but fully specified
template business process descriptions which include at least template
schemas for the actual data to be exchanged at each step in the process. I
would assign an "A" if it developed not just templates but recommended
implementations for the set of procurement transactions and processes most
used by SMEs. Something like an updated SIMPLE-EDI, perhaps. Comparing the
May, 2000 state of the work with those criteria, I don't think a "C"
compromise is appropriate and will stick to a "D".
>
>
> 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.
It pains me very much to assign "D"s in those areas, since I really do
believe that the Core Component work has the potential of being ebXML's most
significant lasting contribution.
Regarding your comments on X12 and EDIFACT, they are beyond the scope of my
analysis ;^)
--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
