WSDL and Schema Parser

• Download demo and source files - 41.4 Kb

Introduction

If you want to aggregate a web service with your application service, or if you are trying to implement someone else's WSDL, then you need to pay attention while viewing them. That means you are encountering the web service interoperability problem. That was the problem I had too, and I thought that having a GUI for viewing a WSDL like tree structure could be really cool.

In my previous article on UDDI Explorer, I presented an approach for searching the web service and parsing the web service description information (WSDL). It focused on UDDI and parsing the abstraction (interface) level of WSDL. I sometimes encounter questions that fall into the same idea of parsing WSDL that also takes into account the implementation of the information level.

In addition to refactoring, this library was developed to patch up the known bugs of the previous article. It aims to achieve better result by improving some features like:

• Bottom-up parsing of WSDL document.
• Collection based parsing of XML schema.
• Generating XML document from XML schema.

Background

If you are not familiar with WSDL, SOAP, XML schema, then before going further please check out these resources:

• W3C WSDL Activities
• Web Services Description Language (WSDL) Explained
• Specifications
• XML Schema Tutorial
• XML Namespaces by Example
• Improve interoperability between J2EE technology and .NET
• W3C SOAP Specification

Parsing the WSDL

As you can see, the WSDL can be represented as a tree structure. The parsing task includes two major modules: WSDL parser and the XML schema parser. The WSDL parsing task goes from the implementation level up to the abstraction level. The parser proceeds as follows:

• For clarity, we first get all the <service> elements. For each <service> element, we jump to the <Binding> element that matches the service, and get the set of operations that the <binding> element includes, and then jump to the <PortType> definition which the <binding> element points to.
• Finally, we find the operations set of the <PortType> element. Parsing such operations is based on the binding information (style, use attributes) and the input/output message declaration associated with them. This process also takes into account parsing of the associated XML schema.

The XML schema parser module includes a process that translates the XML schema structure into a tree that looks like the XML instance of each SOAP message. It is featured in detail below:

• Reference type definition

  Reference definition is a mechanism to make schema simple through the sharing of common segments/types. In the process of transforming this structure into a tree, I chose to duplicate the shared segment under the node that refers to it.

• Preventing infinite recursive definition

  This happens when a leaf element refers to one of its ancestors. (I.e. A class has a member as an instance of it.) This structure definition will also break the tree structure and it has to be solved differently from the way of solving reference types, otherwise it will fall into an infinite recursive loop. In this case, it just shows the node (which refers to its ancestors) with a predefined depth.

• Handling multiple schema elements

  This occurs when an element has an unbounded value for the maxOccur attribute. It will be treated by duplicating the same element.

• Handling the inherit definition

  A complexType which is defined based on other types will be built as the derived structure. That means the derived node contains the base node elements.

• Handling the namespace

  If an element form is qualified, the XML element should be displayed in the qualified name.

It turns out that there is no easy way to do parsing of the XML schema due to its structure which is extremely rich and complex. Due to the declaration difference between the operation styles of Document/RPC, the input/output tree might be different. We can extend the result of XML schema parser to solve the problem of generating XML document from XML schemas.

Using the library

The view displays the service name, protocol, port, the collection of operations that are exposed by the port and their parameters. Depending on the complexity of WSDL and the server status, the TreeView may take a few seconds to render. Move your cursor over any operation element to view the input/output parameters associated with it.

This library contains two major parser modules as mentioned above. The extra module helps you to create XML from a tree node; in this case it generates XML data from the XML schema tree. You can use them in both 1.1 or 2.0 Framework.

I've tested it on some quite big web services with size larger than 10000 lines and with a complex schema definition, by just entering the web service address and clicking the Parse button. Now, let's take a look at how the tree looks like!

Conclusion

Web services are still growing up and going to play an important role in distributed computation. However, there are many misconceptions that exist in this technology. At the basic level, this tool can partially help you in creating the business process. I will stop for now and expect to have more time to enrich the explanation.

My special thanks to Marc Clifton and Lluis Sanchez for their works on XSD and WSDL generation that helped me in saving my time for implementing such things.