The cousin to yesterday’s WSDL Anti-Pattern: The ‘Single XML String’ Service is the use of the XSD specification’s ‘any’.

‘Any’ literally means “any well-formed XML contained in this section is valid”. ‘anyType’ means “any valid XSD Type”. We can start to see the correlation between the Single XML String service and the use of these generic types. They are used to dilute the definition contained in the WSDL to attempt to account for unforeseen changes in the future.

The benefit is that the WSDL doesn’t need to change as the service evolves, even though the services themselves will have to be modified to support the new arbitrary types.

The drawbacks are numerous. Tooling support for xsd:any’s is also low. You lose message validation. You lose strong definitions of your service. All the points that were made in the previous post apply to this style as well.

This is not to say that there aren’t valid reasons to use ‘any’ and ‘anyType’. Say, for a service that dynamically routes messages based on header contents. It’s just that most of the times they are used, it’s for the wrong reasons. Yes, I’m talking about you Industry Standard Schema Definitions (easily the worst offenders).

Just in case you didn’t like any of my arguments, here is a very well written DeveloperWorks Tip on using generic types with WSDL and the pitfalls that can occur:

Summary

Although it may seem like a good idea to use xsd:any in your Web service’s XML schema, there are pitfalls to doing so: you are deviating from the intent of WSDL, and the language mapping of xsd:any may not be easy to use. Although I won’t go so far as to say using xsd:any is a bad practice, I do hope this tip has given you a better awareness of problems you may encounter before you encounter them.