Interoperability is often a harder problem that I generally let on in this blog as due to the huge variety of implementations out there, there are subtle variations on how one constructs doc/lit, rpc/lit and rpc/encoded messages on the wire. Depending on how it is done, you either help the consumer or hurt them.
For example, right now I am in the middle of an customer escalation where the customer has chosen an rpc/encoded approach to model a document oriented exchange. When both sides are the same vendor's SOAP implementation it works like a charm because it is a homogeneous environment. However, as soon as you bring in nearly any other SOAP stack the other stack chokes and you either have to write a custom serializer, look for a one-off relaxation fix from the vendor for a solution to this problem or suggest having the exact same server on the client side. None of these are particularly attractive when you don't control the client ... a more proactive approach is to be more thoughtful up front when designing the service.
I wrote one article two months ago suggesting top down design as a way to maximize chances for interoperability but at a pretty high level. These articles from Sun tackle the issue in detail and discuss pro's and cons of appoaches to interoperability:
http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/index.html
http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns2/index.html
As a result of these, my colleague, Eric Rajkovic who often is our diagnostics experts with these kinds of issues, has submitted a paper to JavaOne in the hopes of sharing his "war stories" on interoperability.
4:50:56 PM 
|
