The Labyrinthine Nature of Web Services

Nearly two years have passed since the notion of Web services 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 , 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
, and SOAP ), 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…

Barriers to adoption
So, what is the problem? Schmelzer and a number of analysts said the problem with ebXML adoption is that many parts of the ebXML
specification are the base Web Services specifications, and at the higher layers of the stack, the vertical industry
specifications such as RosettaNet. Seeing as Web services is the preferred approach of choice, many think it will be difficult
for ebXML to find it’s place in the high-tech world, and will then have to serve as a profile of Web services.


Others disagree, such as Sun Microsystems’ Job Bosak, who is also the chairman of the Universal Business Language Committee at OASIS. Bosak said that
he sees ebXML as simply the next version of the aforementioned EDI concept. He feels Web services as currently defined won’t work
for EDI because it is missing the business process definitions and trading partner agreements layer needed to make EDI work in
practice.


In an e-mail exchange with internetnews.com, Bosak explained: “I’m not “grudgingly accepting” of Web services; I just don’t
find them relevant right now to the implementation of EDI on the Internet. I’m willing to take it as given that Web service
technologies can eventually be built out to function in the EDI space, but I can’t see why any of us would be interested in the slow
development of a basically proprietary version of XML EDI when we already have a complete, free, nonproprietary XML EDI stack from
the UN. My question for Ron Schmelzer would be: why should I wait for a klutzy way of doing XML EDI owned by Microsoft and IBM when
I have already have a more coherent solution developed by EDI experts and in the public domain?”


Bosak went on to say that a melding of Web services and ebXML wasn’t necessary. Rather, to cross the boundary into the enterprise,
Bosak believes the UBL he is working on can provide the XML librabry needed to do this.


What is interesting here, is the polarity of philosophy Bosak pointed out, which highlights Sun’s disagreement with fellow software
makers Microsoft and IBM on how to approach EDI. In Bosak’s view, Sun stands for open standards, and he suggests Microsoft and IBM stand for proprietary approaches.


Gartner analyst Daryl Plummer disagreed with Bosak’s view.


“To say that Web Services is proprietary or is “…owned by Microsoft and IBM…” is misinformed at best and disingenuous at worst,”
Plummer told internetnews.com via e-mail. “I do agree with him that Web services are not yet ready for full EDI use and that
ebXML is better positioned to handle that situation (EDI). However, to dismiss Web Services in this context is short sighted.”


Another analysis
Giga Information Group analyst Uttam Narsu had this to say when apprised of the opinions expressed in this article:


“I’m reminded of the various blind men who examine parts of an elephant and conclude that it’s variously: a snake, a rope or
two swords. The problem is also akin to the argument that software is needlessly complex and that “each Microsoft Word user only
uses 10 percent of the features.” While that may be true, each user likely uses a *different* 10 percent subset of the features.
In fact, I see the use cases as being quite distinct and also encompassing the differences between document-centric message
exchange, application integration (typically asynchronous and at 4 different levels– data, logic, presentation and process) and,
lastly, pure synchronous RPC-style interchanges.”


How does Narsu see the issue shaking out?


“So I see adoption of ebXML by the top tier of companies (95 percent of Fortune 1000 who are using ebXML, but only 2 percent of
SMEs), and Web
Services by almost everyone else. Each will have its place, and bridges will be built to insure interoperability– that path was
laid when ebXML adopted SOAP 1.1 with Attachments as a base format for exchange). Adoption of ebXML by the core EDI using community
seems to be a foregone conclusion (as long as UBL succeeds, and quickly). That’s because the parallel work ANSI ASC X12 did was
*abandoned* in 1999 with the advent of ebXML. UBL is the likely realization of the ebXML business components, so in the long term, I
imagine it will be the agreed upon standard.”


Narsu also weighed in more heavily on the polarities between Microsoft/IBM and Sun.


“Schmelzer’s view is *exactly* the view espoused by IBM and similar to Microsoft’s view. They’d like to see ideas that they have
developed in Web Services adopted by the ebXML crowd. Bosak’s view is that of Sun. I may be giving Sun too much credit (especially
because their strategic view of Web Services has always been fuzzy), but by hyping up the “you can do anything openly with ebXML
that you can with proprietary Web Services”, they are doing exactly what Sun has to do (in
their minds) to be invited to the party.


“The worst fear of IBM and Microsoft is that Web Services bifurcates. Sun is therefore playing against this fear. And in a way, they
have a hole card. ebXML is becoming real, and is of interest to government agencies and the international community. In fact,
despite ebXML’s current ‘vaporware’ status, it one ups Web services on the standards front. Add the W3C to the mix– where Sun has
the ownership of the Technical Architecture Group chair, and where they’re concerned about standards (the new WSDL requirements doc
specifically mentions ebXML) and the Semantic Web, and there’s this anti-MS/IBM message that’s starting to play. That message harps
on standards, and patent-free specs and code. Since it could damage the Web services freight train, I bet IBM and Microsoft will
have to stage a rapprochement with Sun.”


Why should you care?
In short, ebXML and Web services are being marketed as processes that will help businesses cut their software and infrastructure
costs. They’ll also have computers and networks performing tasks that people used to do. If you
are the software vendor developing Web services apps, look out.


To quote a few research firms, IDC predicts the professional services around Web services-related projects to generate $7.1 billion
in the United States by 2006, representing a spectacular compound annual growth rate (CAGR) of 116%. IDC defines professional
services related to Web services as consulting, application development, and system integration activities that are performed by
external services organizations based on the Web Services Architecture(SM) (WSA) concept.


And someone has to secure Web services, right? ZapThink believes the market for Web services security will balloon from $40 million
in 2001 to $4.4 Billion by 2006.


Some groups, such as The FactPoint Group, believe Web services adoption in North America is already blossoming. After conducting a
survey consisting of in-depth interviews with 50 enterprises plus 796 respondents, FactPoint partner Tim Clark said: “Some
IT-oriented research firms are advising clients to go slow on Web services, and that is exactly the wrong advice,” said Clark.
“Almost half of the respondents to our survey this spring are already piloting or deploying live applications based on Web services.
In fact, Fortune 1000 companies are the most aggressive adopters of Web services applications. They are clearly convinced that Web
services are a strategic technology.”


So, how far does the Web services/ebXML rabbit hole go? No one seems to be sure. Many analysts say we’ll have a better idea in one
to two
years, when more and more companies are believed to begin rolling out secure packages. There is clearly considerable interest among
software giants to corner the most valuable parts of the market.


For more technical viewpoints examining various uses of ebXML, please view the presentations from the XML Barcelona conference
from May here.

News Around the Web