Author: Roger Smith
XML, by itself, can’t be a lingua franca, since it really isn’t even a language; it’s more an alphabet or limited set of characters for sending information between application systems. And just because applications speak XML doesn’t mean that they can talk to each other, anymore than English and French speakers will understand each other despite using languages based on the same alphabet.
For two applications to communicate they must also agree on the specific data standards to be encoded in XML, hence all the current squabbling over Web services (W-S) standards. Case in point is the proposed reliable-network protocol that identifies, manages and tracks the reliable delivery of messages between source and destination Web services. Currently, there are two competing specifications: WS-Reliable Messaging (using a specification supported by IBM, Microsoft, BEA, and TIBCO) versus WS-Reliability (promoted by Oracle, Sun, Fujitsu, Hitachi, Sonic Software, among others).
WS-I to the rescue
The growing number of products and standards is playing havoc with the key Web services concept of interoperability. At a W-S event not long ago, Steven Ross-Talbot, co-chair of the Web Services Choreography Working Group at the World Wide Web Consortium (W3C), said he counted 31 Web services specs currently on the drawing board, many of which overlap. The Web Services Interoperability Organization (WS-I) is an open industry effort chartered in early 2002 to promote Web services interoperability across platforms, applications, and programming languages.
Much of the work of the WS-I in the last few years has been to provide a document called the Basic Profile (BP). This document focuses on a handful of core Web services specifications such as SOAP, WSDL, XML Schema, and UDDI, and provides specific guidelines and recommended practices for using and developing interoperable Web services.
| Figure 1: The WS-I Basic Profile can be used to analyze a web service for interoperability across the discovery, description and messaging layers of the W-S stack. |
Since it is possible to test for specific interoperability problems, the WS-I has also put together a suite of test tools that will check a Web service’s message exchanges and WSDL against assertions in the Basic Profile. The testing tools are used to monitor and analyze interactions with a Web service to determine whether or not the messages exchanged conform to WS-I Basic Profile guidelines. Testing for conformance to the WS-I Basic Profile means analyzing Web services for interoperability across three areas or layers in the W-S stack:
- discovery of a service via a UDDI registry entry;
- description of a service using WSDL;
- Messages being exchanged by a running service, which usually takes place over a network.
Making sense of the conformance report
The WS-I testing tools, with implementations in both C# and Java, can be used on any Web services platform to generate a WS-I Profile Conformance Report.
| Figure 2: This Web service passed the WS-I interoperability tests despite missing input in the UDDI registry section. |
The Summary section of the WS-I Profile Conformance Report tells if a Web service’s WSDL file has passed or failed the WS-I interoperability tests. The WS-I Profile Conformance Report is divided into the three areas (discovery, description, message). The discovery section of the report covers the conformance of a Web service’s entry in a UDDI registry. In the sample report shown in Figure 2, a UDDI registry was not used — so all the assertions are flagged as Missing Input. The description section of the conformance report shows whether a W-S assertion is either “encoded” (a previous W-S norm) or “literal” (the interoperable standard required by the WS-I Basic Profile.)
The message section of the report shows if there is a mismatch in the format of messages being passed between a client and a Web service, either at the transport level (using HTTP, etc.) or at the “wire” level (using SOAP and WSDL.) A test assertion on the conformance report may have one of five possible results: passed, failed, warning, notApplicable, or missingInput It’s worth noting that the “missing input” result by itself will not cause a service to fail (as is the case in Figure 2).
WS-I and maturing standards
The WS-I is a unique kind of a standards body, since is it doesn’t really define standards but instead defines guidelines and test kits. Whereas conformance tests from others organizations such as World Wide Web Consortium (W3C) and SoapBuilders tend to focus on a particular specification, WS-I test tools are designed to address interoperability at a level above that of specification-by-specification. Each of the four specifications– XML Schema, SOAP, WSDL, and UDDI– in the WS-I Basic Profile have been developed or are currently managed by other organizations, such as the W3C and UDDI.org. As Web services standards mature and more profiles are developed, there is every indication that the WS-I will adopt specifications from additional organizations, especially in the all-important areas of orchestration, security and quality of service.
Open source and interoperability
According to a FAQ (www.ws-i.org/FAQ.aspx) on the WS-I website, WS-I’s work is targeted at four primary consumers:
- End-user companies and developers;
- IT vendors producing Web services tools, platforms, and products;
- Architects of business and enterprise systems applications who want to understand and use the guidelines and specifications WS-I delivers; and
- Project manager and bench developers who require access to the development processes and testing tools from WS-I’s best practices and conformance specifications.
Web services is a rapidly evolving technology, and a good argument can be made that open source developers, with their widespread community involvement, belong on this list.
The reasoning here is relatively straightforward. One major premise is that open source developers can much more easily keep up with rapidly changing technology like Web services than can a single, proprietary vendor. Web services are all about interoperability. In the WS-I lexicon, “interoperable” means suitable for and capable of being implemented in a neutral manner on multiple operating systems and in multiple programming languages.
To prove that a Web service is interoperable, it needs to be tested under a large number of circumstances and incompatibilities need to be reported to the WS-I. The open source community is extraordinarily well equipped for this work, since most open source developers are already familiar with a rapid evolutionary software process: testing widely-distributed applications, fixing bugs, building a common knowledge base, and adding this knowledge to a suite of regression tests to make sure their applications don’t break again in the same way.
Open source developers should also be familiar many or most of the open source products in a W-S stack (operating system, database, application server, Web server, servlet engine, and SOAP engine) such as Linux, MySQL, JBoss, Apache, Tomcat, and Apache Axis. Apache Axis is a faster and more flexible rewrite of the old Apache SOAP, which has full support for WSDL and the most recent JAX-RPC API.
Another premise that open source development shares with Web services is openness. Open source developers who are use to reading, redistributing, and modifying the source code for a piece of software should feel very comfortable with the WS-I notion of interoperability that says everything you need to know about a Web service in order to use it should be available for inspection via the various Web services protocols. (Unlike open source, however, a Web Service requestor is unable to change anything in that description or affect the behavior of the service.)
It ain’t Shakespeare
The highway of application integration is littered with the corpses of various Remote Procedure Call (RPC) architectures such as CORBA and DCOM. It’s too early to determine if Web services and the interoperability approach championed by WS-I will overcome the shortcomings of previous integration approaches. The WS-I’s Profile approach may very well be the highway-to-nowhere rather than the road-to-success, but we shouldn’t overstate the difficulty of doing this type of interoperable machine-to-machine communication.
By reducing the number of options that Web service developers are permitted to use, WS-I Profiles should force some agreement on basic documents in the maturing W-S vocabulary. Fundamentally, building interoperable Web services means creating a kind of informal Esperanto.
Like other pidgins or trade languages, Web services are essentially just a way to buy and sell merchandise, or haggle for a better price. Forcing agreement on a few basic Web services terms shouldn’t be all that difficult. After all, it ain’t Shakespeare. Or even Moliere.
Roger Smith is a Bay Area-based free-lance writer and a regular contributor to our pages. He is a former technical editor of Software Development magazine.
