Nearly two years have passed since the notion of Web services (define) was thrust into the public eye as a lucrative approach to conduct electronic business over the Internet, but the concept has hardly grown stale for the analysts and business people who cover the high-tech sector. It's just morphed a bit. Or has it?

Web services is the latest and clearly favored denomination invoked to describe a way of allowing computers to interact and make decisions based on the data that has been fed to them. That much is true. But what non-analysts or non-standards gurus may not know, is that there are other options, albeit ones that are not as popular today. Yet analysts and standards workers have maintained that schemas such as ebXML , or electronic business Extensible Markup Language, remain viable.

With ebXML, the focus is a little less broad than Web services, although the computers-talking-to-one-another ideology remains the same. Fostered by standards groups United Nations Centre for Trade Facilitation and Electronic Business(UN/CEFACT) and OASIS, the goal of ebXML is to enable a global electronic marketplace where enterprises can meet and conduct business with each other through the exchange of XML-based messages. Or, as Ron Schmelzer, analyst with XML and Web services technology research firm ZapThink, says: "ebXML envisions a future where businesses can describe their interfaces electronically and then allow businesses to dynamically locate those interfaces and then bind to them when they choose to actually do business. It's a good vision, but depends on two big things: standards and the actual implementation of those standards by businesses."

And the folks who are trying to propel ebXML forward are looking to achieve semantic interoperability, according to OASIS President Patrick Gannon, whose group recently presided with UN/CEFACT over an Interoperability Summit in Orlando, Fla.

Gannon, and many industry watchers, said a major barrier to ebXML is that many developing organizations are working toward the same goal, but in a different fashion, with different approaches, rules, and even written code.

"Since the establishment of XML 1.0 in February 1998, there has been a proliferation of vocabularies, and no universal move to establish one," Gannon told internetnews.com. "Ultimately what is needed are common frameworks so e-commerce can achieve true global interoperability."

Since the ratification of the first ebXML spec in May 2001, OASIS has been working on furthering ebXML.

Web services versus ebXML
For those that go back a little ways in the software networking annals, ebXML is meant to be an extension of EDI (define), or Electronic Data Interchange. ebXML has also been around for a couple of years -- the messaging aspect of the seven-parts of the ebXML standard was ratified in 2000. Moreover, Forrester Research said a couple of years ago that EDI would be replaced by "Web-hybrid" systems facilitated by ebXML.

The end purpose in all of this is for the computer and corresponding network to fill items such as purchase orders, and to fill them intelligently. For instance, if a computer has two copies of the same purchase order, with the functionalities provided by ebXML, the computer will know that it should only process one of them. This can be crucial in businesses whose systems process POs numbering in the millions.

B2B arrangements are devised of horizontal and vertical parts. On the horizontal stacks, there are software functions such as messaging, routing and packaging data. On the vertical side, there are business processes, such as a purchase order. That's in general; there are cases where a PO can be part of the horizontal stack.

As Forrester Research analyst Ted Schadler pointed out about ebXML stacks, bottom layers hear each other and understand what the other is saying, the middle layer consist of those that hear each other and know what the other is saying, and the last layer is the actual business process or trade, such as a purchase order. That is what ebXML seeks to enable.

But can ebXML and Web services work together toward the same goal of conducting seamless electronic business? Like the standards themselves, opinion bifurcates.

ZapThink's Schmelzer said ebXML will eventually meld with the efforts of Web Services to provide a context for how Web Services will be used in a business-to-business manner.

"Basically, ebXML is a much more robust mechanism for performing business-to-business dialogues in a completely electronic, loosely coupled, dynamic manner," Schmelzer told internetnews.com. However, Web Services has a parallel goal of enabling system-to-system interactions utilizing a standards-based framework. The problem is that Web Services is not robust enough in its current incarnation to actually accomplish reliable, secure, asynchronous e-Business interactions. As a result, ebXML is filling that gap."

However, Schmelzer said ebXML won't be too viable to maintain two separate stacks -- one internal, one external -- for B2B interaction. This, he said, will lead standards groups and vendors to ebXML specifications into the base Web Services specifications.

"In effect, ebXML is becoming a "requirements generator" for what Web Services needs to be for B2B interactions," Schmelzer said.

As it stands now, and without going into the exact nature of what every spec does, the specs of the ebXML stack consist of messaging, description and registry in the lower levels. Problem is, Schmelzer said, Web services specs, (think XML, UDDI (define), and SOAP (define)), provide these functions as well. While the first few layers are relatively simple, Schmelzer said it gets increasingly difficult as one progresses up the stack ladder.

"Therefore, it makes sense for ebXML to 'bolt on' to Web Services standards to help flesh out what is becoming increasingly in more widespread use," Schmelzer said.

Stumbling blocks to ebXML and disparate viewpoints...

Go to page: 1  2  Next