Rawlins EC Consulting

Rawlins EC ConsultingRawlins EC Consulting

Rawlins EC Consulting - Help! Rawlins EC Consulting - Contact Rawlins EC Consulting - Resources Rawlins EC Consulting - Services Rawlins EC Consulting - About

 

Analysis





XML Resources





EDI Resources





General EC



 

 

ebXML - The Road Ahead

 

This series, for the most part, has focused primarily on ebXML deficiencies and on the past. I will close this series by making a few observations on ebXML accomplishments then turn to the future.

 

First, what did ebXML do right? I don't want to belabor this very much because so many others have done such a fine job in beating the drum. However, a few things are worth mentioning. The most significant thing that ebXML did right was its delivered specifications and reports. Despite the deficiencies I've noted, taken in overall context they represent a significant positive contribution to advancing electronic business. My previous article discussed the ebXML Core Components work, but I also in particular want to single out the Message Service Specification. It is one of the few documents that focuses squarely on a very common problem in need of a solution, and provides that solution in a comprehensive and thorough fashion. I have a few suggestions for improving it, but on the whole it is a very good piece of work.

 

ebXML was also in many ways a significant success in terms of participation. It was quite an accomplishment for the sponsors to involve such a wide, deep, and diverse group of organizations, companies, and individuals. In the end, they even got Microsoft involved, which in itself was no small feat.

 

Finally, ebXML was a somewhat qualified marketing success. There is almost no one in IT or e-Business now who has not at least heard of ebXML. They may not necessarily understand what it did, but at least they've heard of it. And, a significant number of organizations have announced support for the ebXML specifications.

 

So, what do UN/CEFACT and OASIS have to do now to continue the work that they started over two years ago? I say "continue" rather than "finish", because work like this is never really finished so long as business and technology keep evolving. I prefer to answer this question by returning to ebXML's original objectives and some recurring themes of this series. These are enabling interoperability and bringing the benefits of e-Business to SMEs. I have suggestions in several areas that touch on both topics.

 

There are three areas in which major work has yet to be done to enable interoperability. These are in the message services (transport, routing, and packaging), business process definition, and business document definition.

 

So, given all that is right with the message service specification, what's wrong with it, and what's left to be done beyond what I've mentioned in previous articles? The biggest problem is that the specification reflects misplaced priorities, and because of this takes too weak a position in several areas. If ebXML really valued interoperability above other considerations, there would have been more instances of MUST, SHALL, and "only" in the specification, and fewer instances MAY, SHOULD, and "default". As a prime example of this, let me point out something that may sound a little silly and pedantic, but that illustrates exquisitely the endemic nature of this problem. Nearly everyone assumes that ebXML will be implemented with IP over the public Internet as the network protocol, right? However, you may be surprised to find that this is not dictated in any of the ebXML specifications. This wasn't just an oversight. IP was deliberately not specified because the TRP team wanted to promote an open, "protocol neutral" solution. But, at the very basic level you can't achieve interoperability if you speak different network protocols. This is an almost pathological pursuit of openness over interoperability. That we didn’t specify IP over the public Internet should be an embarrassment to all of us who participated. UN/CEFACT and OASIS need to bite the bullet and take a stand on this.

 

Another illustration is the failure of the message service specification to specify a file or data transfer protocol. Again, this was done in the name of openness. If we care at all about interoperability, I see no excuse for failing to specify some subset of HTTP, SMTP, and FTP as the approved protocols. Only two would be best, but I could live with all three so long as some comprehensive, coherent recommendations were made about appropriate uses of the three. Again, we don't achieve interoperability if my application talks ebXML over CORBA IIOP, and yours talks IBM's MQ Series or RPCs a la RFC 1831. Even more to the point, SMEs and vendors of SME software need some reasonable guidance about whether to support HTTP, SMTP, or FTP, since cost-wise it may not be realistic to ask them to support all three.

 

As a final point regarding the message service, there is the troubling matter of security. There are valid business reasons for different types of countermeasures. But, as I said before, the message service specification gives too many options. It does require XML Signature (aka XML DSIG) for a persistent digital signature on the SOAP Header and Body elements, but that is about as strong a statement as it makes. It recommends XML DSIG to sign the payload, but doesn't require it. It views payload encryption as being out of the scope of its responsibility. (Is it tacky for me to ask, then whose responsibility is it? "The application's" or "the impelmentor's" are not acceptable answers.). It recommends using S/MIME security for payloads for now, and states that XML Encryption shall become the default once it becomes an official W3C Recommendation. However, none of this precludes other approaches. Overall, the message specification is the only logical place for security specifications, and it is lacking. The recommendations it makes are fairly weak, and even at that they represent a large set of combinations that are not compatible with each other. What would be a great help in this area is exactly what the ebXML Technical Architecture Risk Assessment recommends - a set of recommended profiles. I have a hunch that a handful of profiles, say somewhere between three and eight, each specifying a set of technologies and their detailed configuration options, would probably handle 80% to 90% of actual e-Business security needs. Instead of having to investigate various options, procure the required software, and configure everything, can you imagine how easy it would be just to say "We use ebXML Security Profile #3"?

 

What is needed in the area of business process definition and business document definition is to finish the work that has been started. The catalog of business processes is OK, but it is only a broad, high level catalog. What is needed to make the whole ebXML BP approach useable is not a catalog but a library of common business processes that have been completely specified according to the UMM and the ebXML BPSS. This would give implementers something to work with so they would not have to start from scratch when defining a business process. Likewise, as much as people were saying at ebXML's inception "what the world does not need is another XML Purchase Order", that is exactly what the market has been looking for. (In terms of being a marketing failure, a significant number of people are still looking for the ebXML Purchase Order). The market really does want a single set of common business documents in XML syntax. Until UN/CEFACT and/or OASIS give them the ebXML version of this, ebXML will not have enabled interoperability. As a final note on business process definition, the starting point needs to be specifying common business processes and documents that are already in wide use instead of new processes, variations, and information exchanges that are enabled by technology. For example, specify procurement using a Purchase Order and PO Acknowledgement, instead of inventing a new process. This is how most SME's and their business applications are currently implemented, and we shouldn't expect them to be completely redesigned. As others have aptly put it, we need to start by paving the cowpath. What use is a superhighway if you are still on foot or in a donkey cart?

 

All of these improvements to ebXML's interoperability status will help SMEs. However, there is another significant thing that would help. That is formal recognition that there will be degrees of ebXML support, and that most SME applications will probably never fully support the full range of ebXML specifications. As I've noted in other articles, full ebXML support isn't feasible from a cost and complexity perspective. However, we are missing the boat if we then throw up our hands and say that the ebXML specifications are of absolutely no use to SMEs. What needs to be done is to scale ebXML down for the SME. A pragmatic solution would be to specify levels of compliance and supported subsets of functionality. Here's one way to do it, dividing run-time support into three levels. The three levels are differentiated primarily by increasing degrees of complexity for both software developers and end users. The higher levels also require increasing degrees of business application modifications.

  • Level 0 - Basic ebXML Connectivity - Supports the ebXML message service using SMTP or HTTP, with a limited number of basic security profiles. These profiles support non-persistent, session based encryption, but offer no support for persistent signature using XML DSIG or persistent encryption. None of these profiles require the Level 0 user to have a public/private key pair, so key management is fairly simple. The interface between the message service and the business application may be a batch, file oriented interface. No native business application support for ebXML. Many organizations could achieve Level 1 compliance by implementing a stand-alone ebXML message package or an enhanced EDI/XML package, and interfacing it with business applications by the usual methods.
  • Level 1 - Enhanced ebXML Connectivity and Basic Business Process Support - Level 0, plus support for the ebXML message service using all recommended file transfer protocols, with a broader set of security profiles than Level 0. These profiles might offer persistent signature and persistent encryption, support authentication and non-repudiation, and require the Level 1 user to have a public/private key pair. The business application supports a basic set of electronic business documents appropriate to the domain of the application, as identified in the ebXML library of business processes. However, the application is not required to natively support ebXML document formats. Business applications may handle business process exceptions manually. No support for the ebXML BPSS or CPA/CPP. Configuration of the application and message service for electronic business is by manual methods. As with Level 0, the interface between the message service and the business application may be a batch, file oriented interface. Many business applications that currently offer good EDI interfaces (EDI subsystems that interface with EDI software packages) could achieve Level 1 compliance without very many changes.
  • Level 2 - Full ebXML Support - All of level 1, plus support for all facets of the ebXML message service, and all recommended security profiles. Run-time access to ebXML compliant registries. Support for CPP, automated negotiation of CPA, and configuration of the message service according to CPA. Internal application data items are linked to UIDs of ebXML BIEs. Support for ebXML BPSS, i.e., application and message service configuration according to BPSS. Business applications offer automated support for business process exceptions, as defined in a BPSS. Real-time interface between the message service and the business application, with corresponding exchange of state information. Nearly every current business application would require significant modifications to achieve Level 2 compliance.

This framework or something similar would give application and middleware developers some well-defined and achievable goals for ebXML support. While I expect that very few could advertise Level 2 compliance, it would be a great benefit to be able to identify products as being Level 0 or Level 1 compliant.

 

In closing this series, I would like to try to summarize all of these observations about ebXML into a single, lasting impression. Overall, I have fewer problems with the work that we did in ebXML than I do with what we didn't do. Most of the problems that I've discussed can be fixed, given enough time and effort. What I most take issue with are our priorities, the choices we made about which problems to address and which not to address. I joined the ebXML effort based on the promise that we were going to address interoperability and the problems of SMEs. However, what we did was took the unique opportunity offered by so many different, diverse organizations and individuals coming together, and tried to fix nearly all of the problems that we've had with EDI and electronic business over the years.  We concerned ourselves with problems that most people don't know that they have, while not doing much about the problems that they know they have.  We focused on developing a near perfect, long term solution at the expense cobbling together a "good enough", short term solution. In the realm of business, even for SMEs the latter satisfies ROI concerns a lot better than the former.   I have a hunch that much of the ebXML technical infrastructure was designed so much ahead of market demand that by the time demand surfaces, newer and better approaches will make it obsolete.

 

In immediate, practical terms we're not much better off now than we were when we started. Nearly a year after the initiative was formally concluded, while UN/CEFACT and OASIS continue to fine tune ebXML, I still have clients who want to know how they can securely move XML over the Internet now and not a year or two from now. And, I still field questions from people looking for the ebXML Purchase Order schema.

 

So, there you have it - ebXML according to Rawlins. Will UN/CEFACT and OASIS fix the problems and finish the work before they exhaust their remaining market mindshare capital? I won't hazard a guess but if they don't then ebXML will at best suffer the same fate as EDI. It will be predominant among the Fortune 1000 and have a pitiful presence outside of that elite community. If that happens, we all will have spent a lot of time and money just dressing the dog up in different clothes. I sincerely hope for a different outcome. But, if it doesn't work out any better than that, there's always "son of ebXML". With what we've learned from this attempt, maybe we'll come a little closer to getting it right next time…

 

April 25, 2002

© Michael C. Rawlins