WSDL is a very useful technology. It allows service providers and consumers to agree on namespaces, operation names, the data to be transmitted in a request and the data to expect in a response. All very good things to know, all in a platform neutral way.

Now, WSDL tells us what all the elements and attributes are for a service invocation. What can we do at the WSDL level to account for future changes to the service? This is where some implementations get it wrong.

When you are creating a service, you can only account for the changes that are expected. Maybe a new product will be added or a field may become depreciated. These are easy changes to account for via the way you structure your XSD definitions. In this case, I would say that the service takes a List of Products thats unbounded.

If the change that is being requested created a structurally different message (via additional fields), then you just have to suck it up and modify the WSDL (either marking the old fields as optional if you want compatibility with current clients) or just making all your clients upgrade. To make my point, I’m going to ignore multiple version service offerings or use of WebSphere Service Registry and Repository.

What I’ve seen though, are services where the providers attempt to reduce ANY potential modification to the WSDL interface. This usually results in a service where the operation takes a single string parameter called ‘xml’. The client is expected to serialize the message itself and include it as a string payload in the request.

What this anti-pattern does is remove the entire point of WSDL and XSD. The ability to know what data to send to a service call and what data to expect back in a response. This is no longer captured at the level it should be. If I am a consumer of this service, how do I know what the XML to be transmitted should look like? I have to go through alternative social channels to get this information. That’s the very problem that WSDL was created to solve!

Other problems with”services as strings” deal with the added complexity that the service implementor and consumer need to perform themselves. Today, you can generate a SOAP/HTTP client for a wsdl automatically. The client will serialize your platform specific objects into SOAP and transmit them. In the anti-pattern, the developers themselves need to call the code to serialize the real content and then pass it on to the generate proxy which serializes it again.

What do you gain through this anti-pattern? Well you are no longer bound to making WSDL changes as the service matures. If a new product is created then the service provider and service consumer’s implementations must be updated, but the WSDL is left alone. This pattern is normally used to allow for ‘dynamicity, to account for changes in the data sent between the two services. The gotcha is that you are probably going to have to modify the implementation code anyway to handle the new data. You didn’t really gain anything, but you gave up strict typing and validation.

I’ve found that when the anti-pattern is used, it’s with good intentions but you are far better off just specifying the data explicitly in the WSDL and dealing with changes through your regular change management process for both WSDL and implementation.