Schema Compliance is the Key to Interoperability

Good Web services interoperability
is an absolute must for a successful SOA implementation, but why
interoperability has been so difficult to achieve?

I think that inability to comply with a published Web services contract
expressed via its WSDL/Schema could be one of the leading causes of
interoperability problems (I use the term “interoperability” pretty broadly here).

For example:

• Many “wrapper” service implementations use positional parameter binding, as I
  described in
  my previous post. This allows a service provider to accept messages
  will never validate against the schema. Then, certain changes in
  implementation (a different binding mechanism, switching from “wrapper” to “non-wrapper”),
  could all of a sudden start causing issues for clients that have never had any
  problems before.

• Some Web services clients always generate messages using qualified local
  elements thus ignoring what is in the schema (the default is actually “unqualified”).
  This may work for some binding frameworks but not for others.

• Different JAX-RPC implementation handle “xsd:anyType” differently. Some generate “Object”
  bindings; some use SOAPElement and some actually allow using DOM’s “Document”
  or “Element” (as an extension to JAX-RPC).
  This would be Ok if serialization/de-serialization
  process did not change depending on the binding,
  but that unfortunately is not always the case.

• Handling of “nillable” (xsi:nil) and required elements. If an element is
  declared as required but nillable, it must be provided as part of a message.
  Instead, some Web service clients omit an element if it is “null” in Java.

My biggest pet peeve is that most JAX-RPC implementations today don’t even
support schema validation out of the box (hopefully this will change in JAX-WS).
I understand that full validation against a schema could be expensive, but can
we at least handle required parameters/fields as they defined in the schema?
Types mismatch will certainly cause an error, why not a missing mandatory field?

Note that I’m not talking about WS-I profiles, .NET/Java interop, and
differences in WS-* implementations. I’ve seen all of the above problems while working
with different Web services implementations in Java (mostly JAX-RPC).

And it is not just about interoperability – reliance on subtle conventions as
opposed to a published contract makes architectures more fragile and more
tightly coupled.

So my advice is simple – write a handler (at lest for development/test
environments) and enable schema validation on the server and, under some
circumstances (i.e., you don’t control the service), on the client. This will
save you from many interoperability problems, guaranteed.