Originally posted by Tom Griffith:
What about if a web service method is looking for specific java objects (for instance, a collection) as parameters? Could a microsoft or non-java client still consume the service?
There is no guarantee that both sides have equivalent objects, collections, etc. In fact you can't even assume that all the parties involved are object-oriented. So trying to exchange objects is generally a bad idea - especially if you are trying to be interoperable.
When exchanging data in XML the closest equivalent to a collection of objects (as defined by XML Schema) is a sequence of complex types. How either the web service or the web service client interpret that data structure is entirely their own business.
Another mundane example is date/time - XML Schema has a build-in simple type dateTime with uses ISO-8601 conventions. A Java application may convert it to java.util.Calendar or java.util.Date, while a .NET application might convert it to a system.datetime structure. It would be however ludicrous to suggest that java.util.Calendar (object) is identical to the .NET system.datetime (structure).
That's why it is important to design the service contract in the domain in which the data is exchanged - so if the data is exchanged as XML then the service definition should describe the exchanged data with XML Schema (which is what WSDL does). Creating the service definition in the domain of service platform just tends to introduce unnecessary problems which usually includes an overly obscure client-facing (WSDL) service definition (ever tried to make sense of a WSDL based on a .NET web service that exchanges ADO DataSets?).
It is also usually not appreciated that you are shifting paradigms once you "step through" that web service interface. In the case of a Java-based web services host you are shifting from the object-oriented paradigm to the service-oriented paradigm. While there are some similarities there are also significant differences.