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 language.
     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 format data.
     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.

Schema wars

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 Edition.
     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 Web services.
     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 lawton@afab.com.