SOA Web Services - Validating Interoperable WSDL

Validating Interoperable WSDL

As we have hand-coded the interoperable WSDL in the previous section, there is no guarantee that it can be implemented as the platforms may not support all the features specified in the WSDL. To ensure that the WSDL is valid and can be implemented use the following steps:

1. Create a test web service for your platform. While creating a test web service, implement all the web service's methods by creating a test code. Ensure that all the input and output documents are covered in the test code.

2. Create client code for testing your web service. Call all the service methods of the test service. Ensure that all the defined messages are exchanged between the client and the web service. Validate the results of each service call.

3. Create a test client on another platform and do a similar testing to that suggested in step 2. If the platform choice for your web service is Java EE, then create a client on the .NET platform to verify the interoperability. If your test web service is on the .NET platform, use Java for creating a test client. Minimally, test the interoperability between these two popular platforms, .NET and Java EE.

4. Now, create a test web service for the other platform and do a cross testing across different platforms as in steps 2 and 3 above.

5. If any of these tests require you to modify the WSDL, do so and iterate through all the steps above until your WSDL is finalized.

6. Once you thoroughly test the implementation of your WSDL, publish it in a UDDI directory.

Interoperability Challenges in Web Services

As seen clearly from the ongoing discussions so far, the introduction of web services provided an elegant solution to integrate the diverse applications existing in this world. Before the introduction of web services, several technologies were available for remote invocation of services. These included, but were not limited to, DCE (Distributed Computing Environment), RPC (Remote Procedure Calls), CORBA IIOP (Common Object Request Broker Architecture Internet InterOperable Protocol), Java RMI (Remote Method Invocation), and Microsoft DCOM (Distributed Common Object Model). Web services differ from these technologies on the following grounds:

• Programming Language Independence
• Platform Independence
• Broad Industry Support

These benefits provided a great business value as the applications written in one programming language could now be easily accessed over the web by a client written in an altogether different language. Also, the existing applications need not be reengineered; they simply need to be wrapped as a web service.

Thus, with the introduction of web services, everybody jumped on the bandwagon quickly and as a result the implementations did not quite adhere to the specifications. Thus, we had several web services that were aimed at interoperability, but did not meet the requirements as the underlying protocol implementations did not match the specifications one hundred percent. The specifications are a number of XML standards, which are widely supported. These are:

• SOAP (Simple Object Access Protocol), used for invoking web services.
• WSDL (Web Services Description Language), used for describing the interface to a web service.
• UDDI (Universal Description, Discovery, and Integration), a service registry for publishing information about web services.

The above specifications came into existence at the beginning of this century. The first one was SOAP. SOAP 1.1 was published as a W3C note on Nov 8, 2000. It provided an envelope to encapsulate the following:

• Application messages
• Encoding rules for data types
• Conventions for representing remote procedure calls

The WSDL 1.1 specification was published on March 15, 2001. WSDL provided a convention for defining application messages, operations, and bindings to SOAP, HTTP, and MIME. The UDDI version 2 was published in July 2002.

Due to a sudden rush to implement these specifications, especially the most important one, which is SOAP, the market saw the SOAP specification published even before the finalization of the XML schema. The then published SOAP specifi cation had its own type system called SOAP Encoding. Eventually, when the XML schema specifications were published, SOAP specifications needed modifications.

WSDL had its own problems. WSDL is more suitable for machines than human-beings. WSDL is difficult to understand and implement due to the many layers of abstraction defined in it.

UDDI comparatively suffered less than these other two specifications. The use of a service registry is not mandatory for implementing and using web services. Thus, this specification was the last one to get published and thus faced lesser issues on interoperability.

The market rushed to implement these various specifications from the notes published by W3C even before the standardization work was completed.