Anshuk Pal Chaudhari

Subscribe to Anshuk Pal Chaudhari: eMailAlertsEmail Alerts
Get Anshuk Pal Chaudhari: 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

In the latter case, from a consumption perspective, clients consuming a service using the proxy stubs generated from the WSDL 2.0-based spec require additional work. If a service is exposed through WSDL 2, then the issues clients will face in consuming the service are:

  1. The commonly available WSDL 1.1-based proxy generators can't be used for generating the proxy stubs from WSDL 2 necessitating WSDL 2 proxy generators
  2. Custom WSDL 2 proxy generator tools might not adhere to standards and can aggravate interoperability issues further.
  3. Tight coupling of the WSDL specification version on the client side for consuming the service will lead to interoperable issues as new versions of WSDL are released.
Mitigating Interoperability Issues with a WSDL Version Management Tool
A mechanism to avoid such interoperability issues is to reduce the dependency of the program /component/code on any single version of a given specification. With this in mind we propose InfWVM (Infosys WSDL version manager), a tool that will relieve the burden of generating the client for services consumption based on WSDL. InfWVM generates a standalone WSDL version-agnostic client based on jax-rpc standards instead of tightly coupled stubs normally generated using available proxy generation tools. InfWVM takes the WSDL of the service (whatever specification version), introspects the WSDL and generates a standalone client. This standalone client can be easily modified to include code for customizing serialization or de-serialization activities, etc.

InfWVM can generate the de-serialization and the serialization components provided the necessary inputs like the schema of the input and the output messages, etc. are provided along with the WSDL. InfWVM also provides a mechanism for converting existing WSDL 1.1-based WSDL to WSDL based on the WSDL 2 specification and re-hosting it on the corresponding SOAP engines. InfWVM is available as a plug-in component that can be incorporated into any of the existing SOAP engines. The basic component design of InfWVM is shown in Figure 2. Its key components are detailed there.

Proxy Generator Component
This component is different from existing proxy generators in that it handles both WSDL 1.1 and WSDL 2 descriptions. It's designed as a façade, based on a set of logical version agnostic interfaces, over existing specific proxy generator tools. Hence the InfWVM proxy generator can accommodate future versions of WSDL too, by plugging the corresponding futuristic WSDL x.x version proxy generator into InfWVM and implementing the Custom Proxy Generator set of interfaces. When the client invokes the proxy generator with the corresponding WSDL, the generator goes through the following steps:

  1. Identifies the WSDL version .
  2. Loads the corresponding parsers.
  3. Loads the corresponding WSDL Proxy Generators.
  4. Generates the corresponding Proxies.
The component configuration is XML-based and editable to include variations in parser details and version-specific proxy generator details.

Version Converter Component
The version converter component in InfWVM converts WSDL 1.1-based WSDLs to WSDL 2-based WSDLs. Looking closely at the WSDL 1.1 grammar and specs, we see that they can be divided into parts to map into the component model of WSDL 2.0. WSDL 1.1 contains six major elements, namely types, message, portType, binding, port, and service. Broadly speaking, the types, portType, binding, port and service of WSDL 1.1 can be mapped to the types, interface, binding, endpoint and service of WSDL 2.0, respectively. This mapping looks fine based on the similarity of the description of these elements for any service. This forms the basis for our conversion tool.

The mapping logic is explained below:

  • Definitions vs Description: The root of any WSDL 1.1 description is the definitions tag, while that of WSDL 2.0 is the description tag. Though name is optional in WSDL 1.1 specs and omitted in WSDL 2.0, targetnameSpace is required in WSDL 2.0 unlike WSDL 1.1 where it's optional. Hence, during conversion, a unique URI for targetnamespace is generated, even though it wouldn't fill in any more tags in that space.
  • Imports: All the WSDL 1.1 documents that are imported also need to be converted to WSDL 2.0.
  • Documentation: Documentation has to be put in the proper places.
  • Types: The types of both WSDL 1.1 and WSDL 2.0 are compatible. Hence, types of a WSDL 1.1 document can simply be put into the translated WSDL 2.0 document.
  • Messages: WSDL 2.0 doesn't differentiate between type elements and messages. Actually, type elements are renamed as message types. Hence, some care has to be taken here to omit messages from WSDL 1.1 description. WSDL 2.0 allows direct references to all elements defined under types except faults. This is to enable use of similar faults for similar operations and to create uniformity. Hence, messages carrying fault payloads are defined under the interface element of WSDL 2.0. Moreover, the references to messages in operations of portType in WSDL 1.1 are replaced by the payloads of these messages directly into the operations using the element attribute for the WSDL 2.0 interface. In case there are multiple message parts, a new message type/element can be created under types, containing the payloads in a complex type. Hence, a single element payload is put in the operations of the translated interface.
  • Interfaces/PortTypes: WSDL 2.0 has molded the concept of portTypes into interfaces. Interfaces are more robust than portTypes on account of their more rigid and a well-defined structure. There are four transmission primitives defined for WSDL 1.1 and they map to the corresponding patterns in WSDL 2.0 as shown:

    One way      -> In-Only
        Request response -> In-Out , fault is associated with outfault, as it replaces out message
        Solicit response -> Out-In, fault is associated with infault, as it replaces in message
    Notification -> Out-only

    However, incases in which multiple fault messages are generated it becomes complex. A decision has to be provided for faults for the messages they replace (in or out).

  • Bindings: Bindings are quite simplified in WSDL 2.0. Operations in interfaces are simply mapped to the MEPs of SOAP messages.
  • Ports/Services: They are analogous to the endpoints and service in WSDL 2.0
Listings 4 and 5 show a sample WSDL based on 1.1 specifications that's been converted to a WSDL 2 specifications-based description by InfWVM.

The WSDL 2.0 standard takes care of the inherent gaps in representational issues in WSDL 1.1. It provides for capturing the required in-depth details of XML messages, simple exchanges between a service and a node, the transport in use, and the service locations. Its extensibility model provides the ability to include non-functional requirements related to a service, such as the security mechanisms or the privacy requirements for the service.

However, due to the current installed base of WSDL 1.1, there are bound to be interoperability issues associated with incorporating WSDL 2.0.

We have dissected the broad differences between both specs. To mitigate the interoperability issues, we propose InfWVM, a tool to help mitigate version management issues with WSDL. This primarly consists of version-specific client stubs generation tools, a logical version-agnostic set of interfaces, and a practical version converter component to help leverage existing WSDL 1.1 descriptions alongside newer WSDL 2.0 descriptions.

The version converter is based on a mapping analysis of WSDL 1.1 and WSDL 2.0 specs. The next step in InfWVM is to extend it and make it capable of defining the constraints and capabilities of Web Services, thereby leveraging the features of WSDL 2.0 beyond the scope of simply defining the definitions of XML messages.


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

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) View Comments

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.

Most Recent Comments
Aram 06/07/07 07:41:18 PM EDT

I think there are some errors, for example:
Multiple services could be declared in the same document in WSDL 1.1. This is not new for WSDL 2.0

SOA Web Services Journal News Desk 05/15/06 11:37:08 AM EDT

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.