The title of this paper is perhaps a little dated, but this is inevitable, few fields that I work in are as dynamic as XML web services have been for the last 2 years. New standards development efforts seem to kick off weekly, agreement and publishing of ratified standards is fortunately some what slower. However it seems to be occupying more and more of my time just staying abreast of the ongoing work, let alone actually participating in the process.

When I submitted this paper’s abstract a few months ago to the selection committee, I had just completed a project involving multi-vendor web services integration. I was feeling rather jaded about the challenges we had dealt with, and the apparent lack of interoperability. This project galvanized me to start focusing on what interoperability really means, and how to achieve it. At the same time I was becoming involved in a design effort to produce reference architectures for our corporate migration to a SOA model.

These two efforts resulted in a change of direction; I decided that what I really needed to focus on was not interoperability, but loose coupling. My journey to find loose coupling started with a survey of current literature, and I had the fortunate opurtunity to attend several excellent presentations by leading authors and vendors on the subject. What became clear from this research was that loose coupling requires interoperability; however interoperability does not necessarily result in loose coupling. In fact in some instances the techniques for loose coupling require significantly less rigorous interoperability than some of the tight coupling techniques.

But I am jumping ahead of myself. Where was I when I started the journey?

Prometric’s predominant development environment is Microsoft Visual Studio .Net, without a doubt one of the best IDEs ever created. The ease with which one can create web services is stunning; the simple application of a couple of references, and adding the attribute [WebMethod] in front of a class’s method, then voila! a web service is ready for consumption. Almost frighteningly easy! Here is a simple extract of one method from a calculator class written in C#.NET:

……….
      using System.Web;
      using System.Web.Services;
      namespace SimpleCalc
      {   public class SimpleCalc : System.Web.Services.WebService    
          {    ……….        
              [WebMethod]        
              public string Add(integer First, integer Second)        
              {   return First + Second;        
              }    
          }
      }
      

So, is this loosely coupled? I would argue that it is not. Consider what happens if the [WebMethod] attribute is removed from the method. Would the method then be more or less tightly coupled to its consumer? It would clearly be less interoperable, as the implementation is then bound to.NET platform interfaces. However both approaches, arguably, produce the same level of implementation coupling. Each approach binds to an interface that is rigid; it would be extremely difficult to extend either without breaking an existing consumer. What was the gain by the use of the web services interface? The answer is language and platform independence, undeniably a significant step. But is that portability really the case? In this simple example there probably really is portability across platforms, the SOAP and WSDL produced should easily be able to be consumed by other platforms. However, extend this interface to use some complex types, collections, or UDTs, and soon the platform independence dissolves.

The SOAP and WSDL specification inevitably left some implementation details up to the vendors, and of course, they took different approaches in places, especially the more complex structures. It is relatively straight forward using the latest IDEs to produce WSDL for a web service interface in .NET that cannot be consumed by a WebLogic Java Application for example.

The recently published WS–Basic Profile attempts to address this issue, which is great news; however it is inevitable that for many months to come, if not years, that legacy version of platforms will not comply with the WS–Basic Profile guidelines so it is unrealistic to expect this issue to evaporate from the real world. Most businesses are unable to keep their platforms at the latest revision, and vendors struggle to stay up with the standards community, the cost of re-development and regression testing is hard to stomach. So instead of relying on the platform to provide loose coupling we need to find another solution.

For a few months I have been conversing via email with a PhD down in Australia, who is passionate about the REST (representational state transference) approach to interface design. Conceptually the approach REST proposes is compelling: Don’t use your platform to produce a complex remote procedure call interface, instead pass a document back and forth, and let this document contain all the state information within it, so the service provider and consumer know how to interpret the document, and respond accordingly. Just like all religions, there are zealots; the REST extremists approach is to say the SOAP protocol in unnecessary and adds no value, rely instead only on HTTP and XML (some even drop HTTP)….. From a pragmatic position I believe that the SOAP protocol, and HTTP for that matter, allows us to leverage many benefits from the platform, encryption, authentication, reliability, routing etc. Could I do these things without SOAP, sure, but they would probably be one off, custom implementations. As with many of these debates there will always be an alternative optimized approach that is far superior to the standards based model, however, we all have to deliver a result on a specific day and time, some times “time is of the essence”. So if there is a way to rely on the platform, and let it do some of the heavy lifting, I think we should let it do it.

So let’s take a look at what the document exchange process actually gives us, how loosely coupled is it? In the document exchange model the service provider and consumer must agree upon the contents of the document, a schema must be agreed upon and referenced by both parties to ensure the document is able to be interpreted. So the consumer and service provider are now coupled by the document schema rather than the interface definition, the interface can simply receive a document, the clever stuff is within the document. Are we in a better place? Are we loosely coupled?

Before answering that question, let’s consider how loosely coupled an interface can ever be. What is an interface? An exchange of data, a request to perform a task, maybe the most abstract way to describe it is as a conversation, and what is the fundamental tool that we use to have a conversation? Language, or more precisely, a shared vocabulary, a common semantics, a way both parties in the conversation know how to call an egg an egg.

I feel like this conversation is getting more than a little ethereal, let’s bring it back to earth. The first step into the world of web-services for most companies seems to involve the exposure of legacy application interfaces simply dressed up as web services, this apparently reaps great rewards, suddenly partners are able to communicate, systems integrate and life appears good. The unfortunate consequence is that the partners are all now tightly coupled. What happens when the service provider decides the revise the service interface? Or changes the semantics they are conversing in? Communications will fail; they are inherently bound to talk the same talk.

There are evolving approaches and technologies that allow this type of wrapped legacy interface to benefit from the loosely couple panacea that web-services potentially can enable. Proxy technologies combined with transformation capabilities can provide a buffer between service consumer and provider, shielding consumers from changes in the service provider, they can act as the Babel fish enabling the two parties to converse using different vocabularies, and even broker varying syntax.

An alternative approach that I experimented with for a while was to design WSDL based upon knowledge I had gained (or googled) about WSDL interoperability. Using this approach I was able to create WSDL that described the service and also was consumable by the clients. The .NET platform has the ability to hydrate server side classes from a WSDL document, this functionality is not readily apparent from the IDE, and requires the use of a command line utility. This approach solved my initial interoperability issues but was time consuming, and in the end this did not produce a loosely coupled interface,(unless of course I had designed it to be so!)

So hopefully you agree; it is clear that there are many approaches to design loosely coupled web service interfaces, but that web services alone are not be the answer. The good news however is that web services can be designed to be loosely coupled, and tightly bound web services can be decoupled.

Whilst I have not provided that many answers, perhaps I have raised enough questions, to provoke some thoughtful design activities next time you put SOAP to work.

The views expressed in this paper are the author’s and not those of the Thomson Corporation.