ebXML and Interoperability

And other issues from the Terms of Reference

The Terms of Reference between UN/CEFACT and OASIS that laid the foundation for ebXML discuss several objectives and issues to be addressed by the initiative. In this article I'll examine how well those were achieved.

The primary goal specified in the Terms of Reference for ebXML was to enable interoperability. To assess how well this goal was met I'll use the definition of interoperability from the ebXML Requirements Specification (section 2.5.1). I'll use a fairly simple approach of assigning a letter grade of A through F (with a 4-point scale) to each of the criteria. Then to keep things simple, I'll average the grades for an overall score, weighting each criterion equally. We'll start off with a perfect "A" for achieving interoperability as the default, then lower by one or more letter grades for deficiencies such as the following:

• Offering options, with a means to indicate the option chosen, instead of a single solution
• Offering several options without reasonable guidance on how to choose among them
• Specification not being complete

Where ebXML didn't address a criterion, I assign a failing "F".

Here are the criteria and my grading. Where notes were included in the Requirements Specification, I have included them here. The basis of the grading is the ebXML work as of the end of the initiative in May, 2001. Further work may (I hope!) improve the grading, particularly in cases where the work is incomplete.

• "Common Business Processes - Both entities involved in the exchange of data MUST be engaged in executing the same transaction in the context of a business process" - ebXML did not define specific business processes, but instead provided a methodology for analyzing and documenting business processes and representing key attributes in an XML document (described by the Business Process Specification Schema). It should in theory be possible to compare two such documents and determine whether or not they describe the same overall business process. ebXML did develop an initial high level catalog of business processes, but with very little specific detail about them. The methodology work (including the UN/CEFACT methodology on which the ebXML BP work is based) is still incomplete in many areas. While the work focused on defining the overall business process context, very little work was done in actually addressing the "same transaction" aspect, i.e., "do we agree on the data to be exchanged?" Grade: "D"
• "Common Semantics - Common meaning, as distinct from words, expression, or presentation" - ebXML developed an extremely limited initial catalog of "Core Components", and an incomplete methodology for developing them. It did provide for assigning a unique identifier to each semantic concept. Grade: "D"
• "Common Vocabulary - A direct correspondence between words and meaning" - The distinction between this and the "common semantics" is a bit subtle. We can have concepts that have a common meaning, but call them by different names. This criterion means we use the same name. The considerations for this criteria can't very well be separated from "common semantics", so I'll grade it the same. Grade: "D"
• "Common Character Encoding [NOTE - UNICODE, which is specified in the W3C XML Version 1.0 technical specification, provides this.]" - Although it is not explicitly specified anywhere in the ebXML specifications that XML is to be used (in fact, some pains were taken to make the ebXML approach applicable to other technologies), I'll be as charitable as possible and assume that we're using XML. So, this one is a "freebie". Grade: "A"
• "Common Expression - Common set of XML element names, attributes and common usage of those attributes, common approach to document structure" - ebXML didn't address this at all. One of the main reasons is that, as noted in my opening article, ebXML's strategy was to enable several existing XML approaches to interoperate rather choosing only one. It also tried to address a very broad scope, with applicability to technologies other than XML. Grade: "F"
• "Common Security Implementations" - Several options are offered in this complex area. As noted in the "ebXML Technical Architecture Risk Assessment", there is little clear guidance on which options might be appropriate for specific situations. That document suggests that profiles be developed to address this deficiency. In addition, there is also a somewhat troublesome deficiency in the lack of clear guidance on key management for public/private key schemes. Grade: "C"
• "Common Data Transfer Protocol" - To support "openness", the Message Service Specification is decidedly agnostic on this point ("protocol neutral"), which might otherwise rate an "F". It does, however, offer protocol bindings for HTTP and SMTP. The CPA/CPP Specification only allows SMTP, HTTP, and FTP to be specified. Let's average these. Grade: "C"
• "Common Network Layer" - Again, I'll be charitable here. ebXML does not specify IP on the Internet, but various other documents support the assumption, along with the expectations of nearly all of the participants, that we are dealing with e-Business on the Internet. Another "freebie". Grade: "A"

Totaling and averaging these, we come up with a grade point average of 1.875, which is about a "C-", or barely average. This is not a very stellar performance for such a highly visible initiative. However, this is not quite an accurate picture. If we assess ebXML's unique contribution by not considering the "freebies" that anyone gets just by doing XML over the Internet, we get an even less favorable assessment. To temper this assessment a bit, I'll omit "Common Vocabulary" since I've graded it the same as "Common Semantics". Averaging the remaining five criteria, we get only 1.2, which is a solid, below average "D". You, of course, may assess ebXML's performance differently for these criteria and may also wish to consider other criteria. My own opinion is that ebXML didn't do very much to enable interoperability.

There were a few other less noticed items in the Terms of Reference that ebXML was supposed to address. In my opinion, we didn't. No one, including me, raised this as an issue to my knowledge. However, CEFACT's initial suggested work plan didn't address them either, so CEFACT must bear a disproportionate share of the responsibility. ebXML was, in addition to the technical specifications, to provide the following two deliverables:

• "An analysis of the current EDI/EC/EB processes and issues"
• "An assessment of the advantages and disadvantages of utilizing XML"

I suppose that one could argue that the first of these two points is addressed indirectly in some of the ebXML specifications and reports, particularly the Business Process documents. I won't make that case, though, and one would be very hard pressed to make a case that we ever considered in a disciplined fashion the advantages and disadvantages of using XML or documented them. XML was pretty much the starting point, not the end result.

So, in regard to the deliverables called for in the Terms of Reference, ebXML did develop a set of technical specifications, but we didn't do a very good job at enabling interoperability. ebXML did not address its other two deliverables. In summary, I would have to say that we failed to meet the mandates of the Terms of Reference. This is a rather severe criticism, and I feel obliged to point out that this is by necessity a fairly subjective analysis; others may have different opinions. I again note that much of the work was incomplete or not addressed when the initiative ended, and the assessment may improve considerably as CEFACT continues the business process and core component work.

I will, however, show in my next article that assessing ebXML's performance in regard to its other major goal is much more objective and clear cut. By nearly any way you look at it, ebXML was a dismal failure in bringing the benefits of e-commerce to Small to Medium Enterprises (SMEs) and developing countries.

August 23, 2001

© Michael C. Rawlins

About  |  Services  |  Resources  |  Contact

©Rawlins EC Consulting 2007