Web services quandary
Tomorrow's business-to-business e-comm requires navigating
the maze of conflicting Web services standards
By Stephen Lawton
Despite the blitzkrieg of standards work, Web services languages today
are in roughly the same position as word processors were 15 years ago
- lots of incompatible choices.
The standards battle is being waged on two
fronts: Consortia are creating competing specifications, as are XML tool
developers. Network executives who ignore the war will be letting these
groups decide which will become the specifications of choice. A worst-case
scenario could find a company building its internal Web services in one
language but its competition - and its suppliers - building in a different
Sorting out XML standards is "a bit of a
rat's nest," says Nathaniel Palmer, chief analyst and director of the
Business of Technology practice at The Delphi Group. The World Wide Web
Consortium (W3C) is working on high-level infrastructure issues, he notes,
while the Organization for the Advancement of Structured Information Standards
(OASIS) is defining practical processes users need.
Some standards complexity is unavoidable
because "XML is not a standard, it's just a mark-up language. Because
it is so dynamic, it can create a new standard on the fly," says Earl
Newsom, a partner in the Integration, Development & Infrastructure Practice
of Deloitte & Touche.
The beauty of XML is that you can create
a language for any application or business process just by defining the
variables in tags. XML uses those tags to understand, move, process and
Curiously, much of the confusion about XML
standards stems from the use of the term "schema," says Paul Harmon, a
senior consultant at Cutter Information Group. The W3C, which created
XML, has an XML Schema standard that defines how to build XML languages.
These languages are also called XML schemas.
Still, conflict among groups is heated. XML tool vendors and consortia
developing XML schemas often compete. It's not unusual to have several
schemas defining the same process. Yet, an application designed to use
one schema cannot access a service built to use a different schema.
This crowd has created four major competing
business-process schemas: IBM has its Web Services Flow Language; Microsoft
has XLANG, which is part of BizTalk, a .Net component; OASIS offers its
Business Process Service, a component of ebXML; and the Business Process
Management Institute (BPMI) has BPML.
Harmon expects only two of these business-process
XML schemas to survive, but can't predict which two. IBM will be seen
as the traditional safe bet, but Microsoft is likely to be the least expensive,
he says. OASIS has the draw of being developed by a standards group but
BPMI's is the most vendor-agnostic.
Meanwhile, back-end application tool vendors
are engaged in the classic struggle between Microsoft and its allies,
such as SAP AG, using Microsoft's .Net technology, and Sun and its allies,
including IBM and BEA Systems, using Sun's Java 2 Platform Enterprise
W3C spokeswoman Janet Daly anticipates consortia
and vendors will eventually tailor XML to vertical industries. "It's one
thing to have specifications that explain XML," she says. "It's another
to build vertical vocabularies."
That work has already begun, in fact. In
addition to creating business-process schemas, companies such as IBM and
Microsoft, and groups such as OASIS, are rapidly building vertical schema.
By some accounts, nearly 100 separate XML-related standards are in various
stages of development.
Ultimately users will likely turn to their
industry consortia - such as the Association for Cooperative Operations
Research and Development (ACORD), which serves the insurance industry;
Business Internet Consortium, an e-business technology provider group;
RosettaNet, a consortium of IT, electronic components and semiconductor
manufacturers; and Standards for Technology in Automotive Retail, serving
the automotive industry - to choose or develop schemas.
One problem with this is that smaller companies
without the clout to dictate schema specifications to its customers could
end up building multiple versions of its Web services for different schemas.
But many find consortia to be a good solution.
Physicians Insurance Corp. (PIC) Wisconsin is looking to ACORD to specify
Web services standards for its members, much like it did for electronic
data interchange. Jay Chenoweth, IS manager at the Madison, Wisc., malpractice
insurer, says ACORD has its own EDI system. Now it has its own XML approach.
ACORD did a lot of work to define XML for insurance providers, by creating
the XML vocabulary for the industry, he adds.
Chenoweth says PIC Wisconsin has begun installing
Web services application server and development tools from SilverStream
Software. PIC Wisconsin expects to have a decision by the end of the month
as to whether it would proceed immediately with its plans for a full-blown
Web services initiative; the initial rollout is slated for mid-2002. He
says the company plans to implement a Java-based implementation of Web
services, although he expects it to be compatible with Microsoft's .Net
Network executives who don't want their
choices made for them should evaluate all the work being done in their
industries, then voice opinions. Options are likely to be offered by all
the players: schemas defined by their vertical consortia, their platform
vendors and consortia collectives such as OASIS.
Lawton is a freelance technology writer in San Bruno, Calif. He can be
reached at email@example.com.