Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo

Microservices Expo: Article

Why WSDL Is Not Yet Another Object IDL

Maintaining a loosely coupled service architecture

There has been much debate lately on what exactly WSDL's purpose is, and much of that debate has focused on whether WSDL is an interface definition language (IDL), or whether WSDL is better used to specify message-level contracts (without any associated operational semantics).

In this article we present an argument that dealing with WSDL as a message-level contract description language is the right way to go for building loosely coupled Web services.

Interfaces and Contracts
Before we delve into the specifics of how WSDL should be used, we need to understand the difference between a classic interface and a contract. By understanding the different problems that each solve we can begin to form a picture of when it is appropriate to use one or the other.

Let's start by briefly recalling exactly what is meant by an interface.

In an object-oriented view of the world, applications are composed from objects - entities that encapsulate state and have a well-defined, publicly visible interface. The interface describes the operations or methods that an object supports and that other objects can invoke. Each method represents an action that, when invoked, may or may not result in the state of the object being changed.

In this object-oriented world, we assume that a shared understanding of how the interfaces of the objects are described exists, that there is a common language for defining them; that's the Interface Definition Language, or IDL. An IDL provides us with a collection of primitive abstractions that we can use to define objects in terms of their interfaces but also with constructs that enable us to create new abstractions (sometimes called "classes" or "interfaces"). The collection of abstractions makes the type system, which is shared throughout our entire object-oriented application. In fact, the type system characterizes the application since more than one type system cannot coexist (e.g., the type system of CORBA, DCOM, Java RMI, etc.).

An abstraction defines the in-memory representation of an object. The interface of an object is the entry point to this in-memory representation. When building object-oriented systems, it is easier to reason about objects in terms of their interfaces since we only need to know how to access the objects and not their actual layout of the in-memory representation. Nevertheless, there is always a conceptual association between an interface and an in-memory representation of an object.

In a service-oriented view of the world functionality is exposed via services that are entities that can send and receive messages. Applications are thus composed by combining services that interact through message exchanges. To enable services to be interoperable, the format of those messages and the message exchange patterns that make the service-to-service interactions have to be agreed on in advance through a contract; thus we need a language with which to express such contracts - a Contract Definition Language, or CDL, as opposed to an IDL.

Unlike an interface, a contract is about the information on the wire and not about how the in-memory representations of objects are accessed. (Note: Throughout this article, we leave the details about the concrete binding of WSDL messages aside and assume that the XML infoset described by the abstract messages is honored by any underlying bindings.) Contracts allow systems to be built from components (services) that have well-defined boundaries (see "References" section) . These services can be developed and evolve independently since they do not share any abstractions. No single type system spans all the components. All that is agreed upon is the information that is exchanged and not how to access any in-memory representation of the objects.

In the Web services arena, a WSDL document is the contract that a service advertises to its potential consumers. Since it is written in XML and (potentially) uses XML Schema, there is no need for shared abstractions or interfaces of in-memory representations.

The big win for this approach is that in any given system we must decide only upon what information needs to go onto the wire. This is a considerably simpler logistical problem to solve than ensuring that all components of a distributed application are able to share a common type system and that all developers (who may well be working for different organizations) understand the operational semantics of the various types in that system. In short, this makes developing distributed applications, particularly those that span organizations, easier and thus cheaper and more robust.

Web Services Description Language
In WSDL 2.0, the wsdl:portType element has been renamed to wsdl:interface (this is true at the time of this writing as per the November 2003 draft of the WSDL specification). Although its name is suggestive, the wsdl:interface element should not be treated the same as a Java interface/class, a C++ class, or a C# interface/class. As we argued earlier, a WSDL document is a contract that describes message exchanges and not a description of an interface for an object.

While it is usually a mistake to do so, consumers of a WSDL document may choose to use it as if it were an IDL document. In fact, many of the current Web services development tools do just that by converting WSDL documents to classes with methods and presenting an object-oriented view of the world to developers.

The wsdl:interface element should be seen as a group of message exchanges in which a Web service is prepared to participate. It defines the set of interaction patterns that are part of the contract a Web service advertises and to which it adheres. The WSDL working group might well have chosen to name this element wsdl:interactions to better represent its purpose.

The wsdl:interface element may contain any number of wsdl:operation elements. (Note: Renaming the overloaded term wsdl: operation as wsdl:exchange while keeping its semantics was discussed by the WSDL working group, but ultimately rejected.)

Again, these should not be treated like the methods of a Java/C++/C# interface/ class although once again current tool support tends to treat them as such. Instead, a wsdl:operation represents the set of messages that are exchanged as part of one of the supported interactions. The alternative approaches are shown in Listing 1.

It is important to understand that a message exchange is described in terms of the information that is on the wire. A WSDL interface makes no assumption about any state changes or correlation between messages, nor does it make any assumptions about what processing occurs in the service's implementation during a message exchange. In that sense, a WSDL interface is far less tightly coupled to its implementing service than the interface of an object that is intimately bound with its instances.

To illustrate these issues, we'll look at a simple library application built using both an object and a service-oriented approach. First, the IDL documents for very simple library and book objects are shown in Listing 2.

It is assumed that the in-memory representations of the Library and Book objects are accessed through the methods available. It does not matter whether objects are passed or returned by value or by reference. There is always the shared understanding on how these objects are represented in memory and how they can be accessed.

Irrespective of different platforms or programming languages that are used to build the system, it is always the case that there are objects that can be accessed through the defined interface. For example, when CORBA is used the CORBA type system abstracts the use of different implementation technologies. The CORBA type system defines the shared abstractions between all the components of the system we are building.

A Library Web service advertises the contract that it expects its consumers to honor. The contract in Listing 3 defines a possible interaction with the service and the formats of the two messages that make the exchange pattern. The contract only talks about the on-the-wire representation of a book and the ISBN. No information is given about the way in which the in-memory representation of the book and the ISBN are accessed. The Web service and its consumer share only the knowledge of XML and XML Schema and so their boundaries are respected. Moreover, when we decide to evolve the application, we don't necessarily have to break existing consumers.

Let's say we want to get the title from a Book object. In order to add this new feature to our application, we will have to change the IDL (see Listing 4) and recompile the entire application since a shared abstraction has changed. It will not be enough to compile only those parts of the system that use this functionality. The change in the shared abstraction may impact the in-memory representation of every Book object in the system.

Evolving the WSDL document, on the other hand, does not need to break existing consumers. That's due to the flexibility of XML Schema and the fact that we do not share abstractions (see Listing 5). While it's true that there will have to be engineering work to upgrade the service to support the notion of a book title, this does not break the application as a whole since no in-memory representations or references to such are being passed around - only conformant XML messages.

Like XML Schema that can be used as a document validation mechanism or a meta-level type system, WSDL is broad enough in its scope to be (ab)used as something akin to an object IDL or as a contract description language. While there are proponents of the former, the simplicity of the contract view of WSDL is compelling since it is a natural fit with the loosely coupled nature of Web services-based applications.

Though WSDL 2.0 may yet provide the features necessary to support both views, we advocate the use of WSDL as a means of describing message exchanges in which a Web service participates. We believe that this approach yields the most loosely coupled system architectures, which are more robust in the face of changing requirements than those systems that impose an object-like view of the world onto a service-oriented application.


  • Box, D. "Service-Oriented Architecture and Programming (SOAP)," - Parts 1 and 2, talks from the MSDN TV archive: msdntv/episodes/en/20030827SOAPDB, msdntv/episodes/en/20030902SOAPDB. 2003.
  • Box, D. PDC 2003. Talks on Indigo and Web services
  • More Stories By Jim Webber

    Dr. Jim Webber is a senior researcher from the University of Newcastle
    upon Tyne, currently working in the convergence of Web Services and Grid
    technologies at the University of Sydney, Australia. Jim was previously
    Web Services architect with Arjuna Technologies where he worked on Web
    Services transactioning technology, including being one of the original
    authors of the WS-CAF specification. Prior to Arjuna, Jim was the lead
    developer with Hewlett-Packard on the industry's first Web Services
    Transaction solution. Co-author of "Developing Enterprise Web Services -
    An Architect's Guide," Jim is an active speaker and author in the Web
    Services space. Jim's home on the web is http://jim.webber.name

    More Stories By Savas Parastatidis

    Dr. Savas Parastatidis is the chief software architect at the North-East Regional e-Science Center (NEReSC), Newcastle, UK. He is NEReSC's expert in Grid Computing technologies and standards. Previously, he co-led an R&D team at HP's middleware division that produced the world's first XML-based transactioning system and represented HP during the early stages of the OASIS BTP standardization effort.

    Comments (13)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    Microservices Articles
    Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
    "NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
    Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
    In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
    The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
    Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
    TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...