Microservices Expo Authors: Liz McMillan, Zakia Bouachraoui, Elizabeth White, Pat Romanski, Yeshim Deniz

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
    The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. In his session at 18th Cloud Expo, Gordon Haff, senior cloud strategy marketing and evangelism manager at Red Hat, will discuss how today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of rec...
    When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes high” is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee A...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine where she evaluated and tested application-focused technologies including app secu...
    Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
    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...
    Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder and Chairman of Alfresco, described how to scale cloud-based content management repositories to store, manage, and retrieve billions of documents and related information with fast and linear scalability. He addresse...
    SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.
    Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true ...
    In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...