Here's an interesting quote: "there is no point in making a Web Service unless you want interoperability" (taken from Steve L.'s "The Wondrous Curse of Interoperability" position paper). I quite disagree with his assertion.
There's really two types of interop Steve is talking about: protocol interop, and runtime type interop. Protocol interop is obviously necessary, else different toolkits can't invoke each other's services, and that would be ridiculous.
Runtime type interop, on the other hand, is completely overrated. Type interop is where a .NET Thneed class instance magically maps to a Java Thneed object with the same properties/fields. This type of interop is completely unnecessary, and can't be achieved.
Here's my feeling: my Web Service has data to offer, and I'm already putting it in to XML format for easy parsing. Furthermore, I'm going to give you a schema as part of a my service's WSDL doc so you can see the structure of my service's data. After that, parsing and processing of the Web Service-based data is your problem -- not mine.
A Web Service designer really should not be worrying about how the wire format of his Web Service data will translate in to an in-memory representation in the consumer's choosen language. Frankly, that's none of the Web Service designer's business. The designer will be doing his job well if he designs an XML schema that naturally and concisely captures the domain information to be conveyed by the Web Service.
Data is, after all, just information about domain objects and the relationships between those objects. If that data can be captured elegantly in an XML Schema instance, then it can also be interpreted and translated ellegantly to in-memory objects/structures/prototypes/etc.
And then again maybe it doesn't even have to be translated in to "ob jects". Perhaps the data will be manipulated as input to XSLT processors; or as the source of XQuery processors; or will be handled in who knows what other manor?
The praxis that the server is not designed around who the client is, or how the client going to do whatever its going to do should be the guiding principal for Web Service message Schema design. Such schema designs will use elegance and natural domain data structure as the inspiration, not incidental client- or server-side implementation structures, nor WS-toolkit vagueries.
Such schemas will automatically be as interoperable as they're going to get. You're just not going to "improve" a Web Service message Schema by trying to shoehorn this natural mapping in to a particular language's or platform's idiomatic scaffolding. (Consider the "java.util.Hashtable Problem" and the "Object Reference Problem".) By definition those kinds of manipulations are going to take your Schema away from the natural and elegant represnetation of domain data, leaving behind difficult-to-translate artifacts in your Web Service's Schema.
By way of example, check out [Udell]. This article describes one developer's misadventures in schema tweaking, and illustrates the confounding polar conflict: coding to toolkit vs. natural domain data encoding.
Remember these core principals of Web Services: high availablility using well-known Internet transport protocols, with XML as the payload data encoding mechanism [Gudgin & Ewald]. If you use a natural encoding of domain information in XML, then these principals alone are enough to support interoperability to all client platforms with a minimal common set of facilities (specifically, Internet communications and XML parsing and processing libraries).
4:32:22 PM 
|
