Skip to main content

XSD:Any is Evil

1 reply [Last post]
Joined: 2003-06-09

We just received a WSDL from one of our business partners. The service had six operations with 12 messages defined. The problem was that each message referred to a data type of XSD:Any. Most java stacks and .NET see XSD:Any as simply data type Object.

Now you may ask what the problem is with XSD:Any - after all it produces an interface which is "loosely coupled". Well the problem is that it produces an interface which is totally useless for the consumer. If you are working with this service in Java, you will see Object Operation (Object arg1). The problem is that you have no idea about what data you need to send or what kind of return value you are going to get back. In this case, you must get in contact with the consumer to get detailed instructions. Doing this obviates the whole benefit of Service Orientation!!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-09-02

If current tools don't support, then it is definitely bad to use xsd:any at the time being.

But definitely it has it's own uses when it comes to extensibility of the service definition. Consider the case of introducing an additional parameter in the result object of a query API.

[b]Old wsdl:[/b]

[b]Old service response object:[/b]


[b]New wsdl:[/b]

[i] [/i]

[b]New service response object:[/b]

[i] New Element2[/i]

As we had xsd:any in the old MyQueryResponse element definition, the clients bound to the older wsdl would still be able to accept the new response with e2 without breaking.

This requirement (ie.) to change the service definition such that the old clients don't break occurs very frequently for some kinds of APIs. As seen above xsd:any solves the problem pretty well. (The other approach to solve this is to host at a new end point. But it is definitely going to be a maintenance nightmare to maintain the old & new versions together).

I am always for service definition being tight. But the above case suggests a use case of leaving loose ends at appropriate points.