Advanced Web Services Interoperability

The Web Services Interoperability Organization (WS-I)

In the preceding examples, a simple string was passed between the services running on different platforms. With interoperability being a major promise of Web services and with simple demonstrations such as this one showing how straightforward it isone would think that Web services are the ultimate answer for disconnected, synchronous systems to interoperate with each other. In practice, this has proven to not be the case. Imperfect specification with levels of ambiguity being used to guide the different implementations by software vendors have led to incompatibilities. As such, unfortunately, it becomes the responsibility of the developer to identify problem areas that may lead to incompatibilities in implementation. Typically the interoperability problems arise with complex data types, but a solution of using simple data types to represent them (such as encoding a complex data type as a string, and passing that string as a simple data type) isn't always best.

In large, mixed-mode systems, root cause analysis for failures is an expensive and time-consuming effort. When data is passed on the wire between systems, the developers of each system may feel that they have done their jobs, and any problems are the cause of the infrastructure or of the other system in accepting their data. This is a bad habit that needs to be broken, for just as the mixed-mode systems are expected to work cleanly together, so are their developers. As such, teamwork around a core set of data types to be passed around is essential, and the "fire-and-forget" mentality that sometimes evolves around Web services development needs to be eradicated.

Additionally, the major software vendors have banded together to form the Web Services Interoperability Organization (WS-I) in February 2002. Its aim is to prevent interoperability problems by designing a typical complex scenario, implementing it in various technology bases, and testing interoperability between each thoroughly. Problems that arise are resolved and published in what is known as a Profile.

This body is intended to complement the W3C that drives Web services standards. It doesn't produce new specifications but instead provides guidance around existing ones. It has a number of working groups whose responsibility is to produce specific deliverables that assist interoperability challenges. These deliverables include profiles, scenarios, use cases, samples, and testing tools. It is highly recommended that all developers verse themselves in the WS-I deliverables before a large scale implementation of Web services, whether they have mixed mode systems or not. The WS-I information is freely available at www.ws-i.org.

The first profile produced by the WS-I is called the Basic Profile [WSIBAS] and was released in April 2004. It states that conforming Web services need to use SOAP, WSDL, and UDDI and provides guidance on using them properly. It also released the supply-chain management scenario that is used throughout this book as an example, and many software vendors provided their implementations that could be used as a basis for other applications that need to interoperate across mixed-mode implementations.

While it hasn't fully solved the problems of interoperability across mixed-mode systems, the Basic Profile and adherence to it has greatly eased them, and is a perfect starting point when designing systems that use Web services. It isn't intended as a guarantee of interoperability but a guideline of the pitfalls that have been discovered to date and how developers can get around them.

The Basic Profile does not take into account the WS-Security specifications, so applications using it cannot secure the message using XML-encryption or an XML-digital signature. However, the wire may be secured using HTTPS.

To solve this, the WS-I have a working draft of a Profile with security that extends upon the Basic Profile [WSISEC] to take into account security requirements whereby portions of the XML packets being passed between Web services may be encrypted and signed.

Additionally, a further area where interoperability within systems is challenged is when dealing with attachments in Web services. This is addressed in the finalized Attachments Profile from the WS-I [WSIATT].

Assuring Interoperability Using the Basic Profile

As part of their participation with the WS-I, vendors are updating their tools to allow developers to more easily build services that adhere and conform to the profile so that their chances of interoperability are improved.

For example, Microsoft has implemented Basic Profile conformance into ASP.NET 2.0, making it easy for developers to build services that conform. This can be done using the ConformanceClaims property on the WebServiceBinding attribute in this manner:

[WebServiceBinding(ConformanceClaims = WsiClaims.BP10)] public class DotNetRetailer { } 

Upon compilation and execution, the WSDL document for this service will contain an assertion that this service conforms to the Basic Profile. Should the developer do things in his or her code that breaks conformance with the Basic Profile, runtime exceptions will be raised because the runtime has built-in conformance validation. Finally, the 2.0 version of the wsdl.exe tool, which is used to generate Web service proxies, will flag exceptions within the WSDL that it is consuming where they violate the Basic Profile.

Web services may also be tested using WSI provided tools that check adherence to the Basic Profile. They intercept the SOAP messages traveling between the Web service and its client. They then analyze these messages along with the corresponding WSDL definition and UDDI entries and produce a report describing whether the service conforms or not.