Shaurabh Bharti

Subscribe to Shaurabh Bharti: eMailAlertsEmail Alerts
Get Shaurabh Bharti: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java Developer Magazine

Java Developer : Article

WSDL 2.0: A Pragmatic Analysis and an Interoperation Framework

Minimizing interoperation issues with a WSDL version management framework

Web Service Description Language (WSDL) represents an IDL describing the contract between the service requestor and the service provider in much the same way that a Java interface represents a contract between client code and an actual Java object. The crucial difference is that WSDL is platform- and language-independent and used primarily (although not exclusively) to describe SOAP services.

The WSDL 1.1 specification has been accepted at the World Wide Web Consortium (W3C) and is the predominant version for describing Web Services today. At W3C, work on the next generation of WSDL, i.e., version 2.0, has been under way for some time now. WSDL 2.0 promises to describe not only traditional SOAP Web Services, but also a wide variety of services provided over any network. W3C has published the Candidate Recommendation for WSDL 2.0. WSDL 2.0 is substantially different from WSDL 1.1. In this article, we'll dissect the WSDL 2.0 spec and point out the overall differences and some core benefits of the WSDL 2.0 specifications. We'll also point out the interoperability issues with WSDL 1.1 and detail InfWVM, a framework for seamlessly working with WSDL irrespective of the version.

The Structure of WSDL 2.0
There are significant differences between WSDL 2.0 and WSDL 1.1. WSDL 2.0 has three specifications:

  • Core, which explains the abstract interfaces independent of protocol and encoding;
  • Message Exchange Patterns (MEP) with predefined types of interactions; and
  • Bindings pertaining to SOAP and HTTP.
The description of a Web Service in WSDL 2.0 is structured into two parts. In the abstract, WSDL describes a Web Service in the form of the messages it propels and receives through a type system. Message Exchange Patterns (MEPs) define the sequence and cardinality of the messages. An operation associates Message Exchange Patterns with one or more messages. An interface groups these operations in a transport- and wire-independent manner.

In the concrete element of the description, bindings denote the transport and wire formats for interfaces. A service endpoint associates the network address with a binding. Finally, a service clusters the endpoints that implement a common interface. Figure 1 shows the conceptual WSDL component model.

Further, different operation styles and message exchange patterns can be defined and a wide variety of message definition languages can be used in addition to XML Schema, with messages bound to any protocol for which a binding specification has been written.

Modifications in WSDL 2.0
Listed below are some of the major modifications introduced in WSDL 2.0 specification

  • WSDL 2.0 is infoset-based, which is more precise and heavily oriented to a component-based structure.
  • An XML Information Set (Infoset) provides a reliable set of information definitions, with up to 11 different types of information items, as explained in the W3C specification at There is no requirement for an XML document to be valid to have information set. WSDL 2.0 provides a set of components and their associated properties for describing Web Services.
  • WSDL 2.0 includes additional semantics. Hence, targetNamespace is a required attribute of the description element in WSDL 2.0, as shown in Listing 1.
  • WSDL 2.0 adds the capability of including documents. Different service definition components of the same target namespace are allowed to exist in separate WSDL documents (which can be used across various service descriptions) using of include element.
  • WSDL 2.0 supports additional Message Exchange Patterns or patterns. WSDL patterns define the sequence, direction, and cardinality of abstract messages sent or received by an operation.
  • WSDL 2.0 has introduced the idea of Interfaces, replacing PortType. The interface operation element has name and pattern as required attributes.
  • The concept of interface inheritance is also introduced in WSDL 2.0. One interface can extend one or more interfaces (multiple inheritance). This adds one more layer of reusability.
  • WSDL 2.0 introduces the concept of features.The presence of a feature component in a WSDL 2.0 description indicates that the service supports the feature and may require that a client that interacts with the service use that feature.
  • WSDL 2.0 supports the use of other type systems (it already supports XML Schema). Schemas are embedded into the types element of the WSDL document. Constructs in semantic models such as classes in OWL ontologies could be used to define the Web Service input and output data types.
  • WSDL 2.0 also introduces the idea of operation style to apply restrictions to an operation.
Addressing WSDL 1.1 Limitations
Listed below are some of the enhancements in the WSDL 2.0 specification that address key gaps in WSDL 1.1.
  • All WSDL constructs have been made extensible via both elements and attributes. WSDL 2.0 provides two extensibility mechanisms: an open content model thatallows XML elements and attributes from other (non-WSDL) XML namespaces to be interspersed into a WSDL document and via features and properties. Both mechanisms use URIs to identify the semantics of the extensions. For extension XML elements and attributes, the namespace URI of the extension element or attribute acts as an unambiguous name for the semantics of that extension. For features and properties, the feature or property is named by a URI.
  • Legacy type definitions like DTD and RelaxNG, which have been in the industry a long time, have been made reusable with support for these definition types in the type definition. It gives an additional level of support for other semantic concepts in the future, e.g. OWL classes. This addresses a key restriction in WSDL 1.1 in the type definition.
  • The lack of interface reusability was one of the major drawbacks of WSDL 1.1 that's addressed by WSDL 2.0. In WSDL 1.1 if we need to deploy an operation across multiple interfaces, it has to be replicated. Even the interfaces declared across different documents can be reused in the existing documents via import or include mechanisms in WSDL 2.0.
  • Multiple services can be declared in the same document, which helps to explore more than one service out of a single WSDL.
  • Previously, since WSDL 1.1 wasn't component-based, instances were used as singletons. Moreover, the component-based WSDL 2.0 has added more compatibility and support for Grid Services, based on a specialized GWSDL, which were started based on WSDL 1.1.
  • Ambiguity in defining operations has been removed by making Qname, i.e, (namespace, local name) tuple unique.
  • The inadequacy of the fault description supported by SOAP 1.1 is addressed and replacedment by the SOAP 1.2 fault format.
  • In operations, WSDL 1.1 had no mechanism to enforce any restrictions, a shortcoming that is also addressed by 2.0. It includes the concept of operation style to apply restrictions to an operation. An operation style asserts that message schemas in a particular operation conform to certain rules.

    Even though 'import' provides a mechanism to get the definitions from a different target space, there was no mechanism available to get the definitions from the same target space. This has been addressed by 'include' in WSDL 2.0

  • WSDL 1.1 had hardwired support for Message Exchange Patterns (MEPs). Only four types of MEPs were supported:
    - Input-output
    - Output-input
    - Input only
    - Output only

    These MEPs corresponded roughly to thefollowing traditional interaction patterns:
    - Request-Response
    - Publish-Subscribe
    - One-way invocation
    - Event

    WSDL 2.0 supports additional MEPS or patterns. It supports the following eight patterns:
    1.  In-only -> consists of only a single message.
    2.  In-out -> consists of an input message followed by an output message.
    3.  Request-Response -> is identical to an in-out pattern except that the in-out message travels on the same channel.
    4.  In-multi-out -> consists of an input message followed by one or many output messages.
    5.  Out-only -> consists of only an output message.
    6.  Out-in -> consists of an output message followed by an input message.
    7.  Out-multi-in -> consists of an output message followed by multiple input messages.
    8.  Multicast-solicit-response -> consists of an input message followed by one or two input messages.

  • WSDL 1.1 didn't support any mechanism for capturing the non-functional requirements of a service. WSDL 2.0 features are introduced for annotating with non-functional or specialized characteristics. WSDL 2.0 features might include "reliability," "security," "correlation," and "routing" related details. The presence of a feature component in a WSDL 2.0 description indicates that the service supports the feature and may require that a client that interacts with the service use that feature. Each feature is identified by its IRI. WSDL2.0's feature concept is derived from SOAP 1.2's abstract feature concept. The feature looks like Listing 2:
  • The SOAP binding for WSDL 2.0 is much simpler and it's easier to write bindings than with WSDL 1.1. The HTTP and XML binding in WSDL 2.0 has also been improved.
Interoperability Issues with WSDL 1.1
Adopting WSDL 2.0 will lead to interoperability issues with existing WSDL 1.1 implementations. Most Web Service implementations are based on WSDL 1.1 on both the producer and consumer side. Interoperability issues with respect to the adoption of the new standard can arise in two ways. First, issues related to exposing already hosted services through the WSDL 2.0 specification and second, issues related to the consumption of the services from the client side using the WSDL based on the WSDL 2 specification. The latter seems to be more difficult to tackle than the former.

In the case of exposing an already existing service using the WSDL 2 specification, one might just have to convert the old WSDL to the new WSDL 2 specification and re-host the WSDL. Since the SOAP engine on the sever side hosting the service doesn't require the WSDL to do its processing, there seems to be no interoperability issues associated with it. Nevertheless, most SOAP engines support automatic generation of the WSDL once a service is deployed. Hence there might be a need to generate WSDL based on the WSDL 2 specification. But this component will be independent of other SOAP engine components and hence can be made available as a plug-in component from SOAP engine vendors and plugged into any of their existing versions of the SOAP engines.

More Stories By Dr. Srinivas Padmanabhuni

Dr. Srinivas Padmanabhuni is a principal researcher with the Web Services Centre of Excellence in SETLabs, Infosys Technologies, and specializes in Web Services, service-oriented architecture, and grid technologies alongside pursuing interests in Semantic Web, intelligent agents, and enterprise architecture. He has authored several papers in international conferences. Dr. Padmanabhuni holds a PhD degree in computing science from University of Alberta, Edmonton, Canada.

More Stories By Anshuk Pal Chaudhari

The authors are interning and/or working as part of the Web Services COE (Center of Excellence) for Infosys Technologies, a global IT consulting firm, and have substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. The Web Services COE specializes in SOA, Web services, and other related technologies.

More Stories By Shaurabh Bharti

Shaurabh Bharti is a Junior Research Associate at Software Engineering and Technology Labs, Infosys Technologies Ltd. He works with Web Services Center of Excellence (WSCoE) team. A Computer Science graduate from IIT Kharagpur, he has been working with the team for almost an year. His current research interests include Semantic Web, Web Service, Contextual Collaboration etc. He has actively participated and conducted training sessions and workshops for Service Oriented Architecture and Web Services. He has also published papers in leading Journals and Conferences for Web Services including ICWS and IJWSP. He was one of the invited speakers at SOA and Web Services Seminar conducted by Vibrant Tech., Bangalore. He can be contacted at [email protected]

More Stories By Senthil Kumar

Senthil Kumar K M was till recently a member of the Web services centre of excellence, SETLabs, Infosys, and specializes in Web services interoperability and Web services security. He has published extensively in different forums and conferences, and filed patents in area of Web Services.

Comments (2)

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.