Udi Dahan posted a few days ago an entry (rant?) on Web Services as an interoperability option between .NET and Java and the potential pitfalls in that. Based on my personal experience, I can't help but agree with him that there's still a ways to go.

Now, don't get me wrong; using Web Services is still simpler in many cases than the other options available, but it's no silver bullet. More to the point, interoperability is not something you get for free; it's something you have to architect, design, code and test for.

Here are some (random) observations on this from my own personal experience:

Know who your clients are and what tools they use

Sometimes you will have to make trade offs in the design of your service contract based on who your service consumers will be and what tools they are using. In an ideal world this wouldn't be necessary, but alas, that's not where we live. For example, Java tools tend to favor certain specific patterns. Or maybe your consumer will be an integration tool or maybe even a legacy platform using one of the many, lesser known SOAP stacks available. Those usually have specific restrictions.

If you know your consumers will be using Java, try to find out what specific SOAP stack they are using (from the plethora available for Java) and explicitly test against it. It will be a worthwhile use of your time. If your consumers are LOB applications, modern third party packages with built-in WS support, or desktop applications (i.e. MS Office) then again special restrictions might apply, so try to find out before hand.

Understand SOAP Encoding and Messaging Patterns

A lot of people still don't know the difference between SOAP RPC/Encoded and Document/Literal. Microsoft took the initiative back in 2001/2002 when the .NET ASMX stack turned on Doc/Literal encoding by default (a wise move, imho), but Java toolkits took a long while to catch up.

Even today, a lot of Java toolkits will default to RPC/Encoded even if they support Doc/Literal and, unfortunately, a lot of Java developers don't know their kits well enough to turn on the right settings. To be fair, a lot of .NET developers don't know how to change the encoding settings either, but we forgive them because of the sensible defaults in the platform

Know the basics

Study and learn how to apply the basics of the WS-I Basic Profile in your platform of choice. Take good care in ensuring you follow the basic guidelines for service/message contract design, and learn what options are available in your platform to control service and message generation.

Here are some good resources to keep in mind for .NET:

• How to Apply the Basic Profile
• Building WS-I Basic Profile Compliant Web Services using ASP.NET 2.0

Beyond the Basics

If you thought interop with plain old SOAP (POS?) could be hard, then be double wary when you get into the WS-* specs, which are sure to complicate things further and bring a lot of extra interop challenges. WS-Security and its related specs, in particular, can give you some nasty headaches. Some thing to watch out for:

• Again, check which toolkits and clients your consumers will be using. Make sure they support the exact protocol versions you expect to be using.
• Make sure you've tested interoperability using the specific protocol features you expect to use. For example, if you're using WS-Security, make sure you can interop at a basic level with the message confidentiality, message authentication options and token kinds you plan to enable.
• WS-Security interoperability problems, in particular, can be nasty to diagnose because most implementations throw extremely uninformative error messages that don't tell you much. Yes, even WCF falls into this trap.
• Watch out for interrelated specs in use. For example, when using WSE to add advanced security to your services, it would by default add a bunch of WS-Addressing stuff that caused extra interoperability issues, because there were several [incompatible] WS-Addressing versions. Add to this that WS-Security was a lot farther down the standardization path than WS-Addressing.
• Know your platform limitations: If you're using .NET 1.1, then you've got very limited options (WSE 2.0); If .NET 2.0/3.0 then at least you have a much more modern WSE 3.0 and WCF options at your disposal.

One hand giveth, the other taketh away

If you're using WCF, understand the choices it makes for you and how to work around them. For example, Data Contracts in WCF aim to improve interoperability by severely limiting the kind of XML structure you can use (elements only and so on). This, however, doesn't help you if you have to work with specific schemas designed by someone else (like standard industry schemas), so be ready to fall back to the old trusty XmlSerializer.

Another thing that might impact you is WCF's default behavior in generating split WSDL descriptions where the schemas are imported (and possibly other WSDL documents as well if your service elements have different namespaces); a lot of external tools choke on those service descriptions. Again, let me point to Christian Weyer's excellent article and code sample to ease the pain of this.

Web Services, Interop