The IDL That Isn't

January 16, 2002

Martin Gudgin and Timothy Ewald

When you listen to someone explaining Web Services, it's not unusual to hear WSDL compared to the Interface Definition Languages (IDLs) used by classic RPC mechanisms like DCE, ONC, CORBA, and COM. All of these technologies use IDL of one form or another to define contracts between components. In all of these cases, use of an IDL was the key to interoperability across language, process, and vendor boundaries. WSDL is exactly like the IDLs of the past in that a WSDL document describes the portTypes or interfaces a web service implements. However, there is one critical difference between WSDL and the IDLs distributed systems developers know and love: no one wants to use WSDL as a starting point. This is a critical problem that will plague the web service movement until it is solved. Let us explain why.

Why an IDL?

When an RPC programmer sits down to develop a new system, she starts in IDL. Her goal is to explicitly define the interface between a client and a server. In principle, the interface defines a semantically-related set of operations the server exposes to the client. In fact, the interface defines both a language binding (which happens to be binary in the case of COM) and a wire-representation for sending messages to other processes. These details are captured in a combination of source code and metadata generated from the IDL definition by an IDL compiler. In some combination, these artifacts are enough to build client and server programs that comply with the interface contract and can communicate with one another by sending binary messages back and forth.

The beauty of the IDL-centric model is that the contracts between components are explicitly stated in a single language everyone agrees upon; at least everyone using the same RPC mechanism. Further, because the rules for mapping IDL interface definitions to programming language source code are well understood, everyone knows how to implement and invoke the operations defined by interface in whichever programming language they choose.

As for web services, if they followed the IDL-centric model, a programmer would start to develop a new system by writing interface definitions in WSDL. Then, she would run a WSDL compiler to emit a combination of source code and metadata that can be used to build both clients and servers that comply with the interface contract and can communicate with one another by sending SOAP messages back and forth.

WSDL is a second-class citizen

But web services don't follow this model. Modern web service tools do not expect developers to write WSDL definitions. From the complexity of the language specification, one might assume that the authors of WSDL have no such expectation, either. Instead, these kits treat WSDL as a second-class citizen. They generate WSDL definitions from existing server-side source code, e.g., a Java class, based on whatever custom language mapping they've cooked up. Whether the WSDL definition can be understood by any other web service toolkit depends on the options it uses for data types and for describing SOAP bindings.

The problems begin

Web service toolkit vendors downplay WSDL because they want to hide it from developers. After all, many web service developers are not all that familiar with XML and the current version of WSDL is notoriously complex. But WSDL is central to how web services work, and this choice leads to a range of problems. We'll focus on two but there are others.

The first problem is obvious. Not all web service toolkits support the same WSDL options. Some support only RPC/Encoded bindings, others support Document/Literal bindings as well. Some support the use of types that were derived by restriction, others do not. Some support overloading the required SOAPAction header or element namespace affiliations on a per-operation basis, others do not. All these issues may be resolved eventually by web service toolkit vendors, who understand that interoperability at the WSDL level is a key goal. Meanwhile, it's up to each and every web service developer to try to make their endpoints as interoperable as necessary and as possible, based on the problem they are trying to solve and the toolkit they are using.

Unfortunately, interoperability is difficult or impossible to ensure if web service developers aren't familiar with WSDL, don't know what WSDL definitions their toolkits will generate from their server-side source code by default, and don't know how to customize their toolkits' behavior. Ask the target audience for web service toolkits, i.e., developers who don't want to know about SOAP and WSDL, the different binding styles and uses and they're unlikely to know what you are talking about, much less how to control which one their services are using. All they'll know is that in some cases, their endpoints don't work.

The second problem is less obvious. Today's web service toolkits assume you'll start development by writing a server, which you'll then expose as a web service. But what if you want to start by writing a client? In the classic RPC model, once an interface was defined in IDL, developers could write clients and servers independently. For instance, CORBA was often used to wrap legacy data sources on heterogeneous platforms. Once an interface was defined in CORBA IDL, a client could be developed at the same time servers were being written. When the client was done, it could use the same client-side proxy code to call objects in different servers: all it needed was the right object reference.

This model would be useful in web services, but it can't really be done today because, while most web service toolkits support generating server-side skeleton code from an existing WSDL definition, they do not guarantee that the server will remain compatible with that original definition even after it is deployed. For instance, if a toolkit generates a server skeleton for a WSDL-defined portType with a Document/Literal binding, but deploys the server with an RPC/Encoded binding, a client based on the original WSDL document will not be able to call it. Without support for this style of development, it will be very difficult to define standard, reusable interface suites for specific problem domains, e.g., supply chain integration, health care, manufacturing process control, etc.

The web service model is a very good one. But it will only be adopted if interoperability is easy to achieve. The best way to do that is to move to the IDL-centric model used by the classic RPC technologies of the past. Ultimately, web service toolkits will have to support a development model that starts with WSDL and web service developers will have to embrace and use that language. To facilitate that, WSDL should be radically reworked by the W3C and ultimately simplified (preferably along the lines we described in last month's column). Until then, WSDL will remain the IDL that isn't.