Best Practice
To design interoperable non-HTTP hosted Web Services use transport protocols that are vendor-agnostic such as TCP, UDP, etc. Similarly, use a transport protocol that corresponds to the expected runtime behavior of the service. It's also a good practice to test interoperability using the components of the Web Service technology stack that interact with the transport such as WCF transport channels or Apache WSIF bindings.

Versioning Strategy
Services are subject to evolve during their lifetime. That evolution often forces changes on the consumers that break the level of interoperability achieved by the solution. Evolving enterprise consumers and services together is not only a very expensive operation that requires massive levels of coordination between both sides; but also violates the autonomy principle of service orientation that says that services should be deployed and modified/maintained independently of each other and the systems that use them.

Best Practice
Define a versioning strategy that considers the interoperability with the existing service consumers. Keeping multiple active versions of the same services maintains a level of interoperability that's not going to leverage the features of the new version. Only implement non-breakable changes at the service, data, and message contract level. Also consider using multiple bindings when changes are required at the transport or message-encoding level.

Stateful Services
A lot of the SOA scenarios in real-world enterprises require stateful services interactions. Those services can maintain the state between calls and are mainly used for long-running operations. Achieving interoperability with those services is always a challenge mainly because there's no widely adopted standard for persisting the state of a service between calls.

Best Practices
When implementing stateful interoperable services; expose the state key using mechanisms that are available to the potential consumers. Typical mechanisms include SOAP headers or transport-specific headers. Also, depending on the scenario, offer different ways for consumers to send the state information.

Governance Interoperability
SOA governance is a key component of a successful SOA solution. However the capabilities of a SOA governance framework are often limited to its capacity for interoperating with multiple services. A successful SOA governance solution requires interoperability between different SOA components such as policies, contracts, or versions that are modeled differently on different Web Services frameworks.

Best Practice
A good practice for guaranteeing interoperability on a SOA governance solution is to have a global representation of the different artifacts such as policies and contracts globally stored on a SOA registry or repository. This approach facilitates sharing global policies, contracts, or SLAs across different business services. Also for some scenarios the global representation needs to be translated to the specific technology representation using some specific technology-specific adapter.

Creating the Interoperable Web Service - Lessons from the Internet
If you've made it this far you might be convinced that it's impossible to create interoperable Web Services. However if we look at the Internet we can find Web Services APIs such Amazon.com, eBay, or Salesforce.com processing millions of requests a day from millions of consumers using a heterogeneous set of technologies ranging from scripts languages such as Perl or PHP to more established enterprises development frameworks such as J2EE or .NET. How did they do it? The following lists some of their secrets for achieving interoperability across the world's largest and most heterogeneous network.
• Simple services, data, and message contracts: Contracts exposed by successful Internet Web Services APIs are very simple and hide the detail of very complex implementations. This guarantees first-level interoperability with a variety of technologies.
• SOAP and REST APIs: Going beyond the debate of whether to use SOAP or REST, the fact is that both approaches can be applied to some scenarios. Supporting SOAP and REST interfaces gives the service consumer the opportunity to select the best approach for a particular scenario.
• Optional use of WS-* protocols: The implementation of most WS-* protocols is an almost exclusive privilege of .NET, J2EE, and C++. Other programming languages like Ruby or Python are just starting down the path of supporting basic Web Service interactions. The use of WS-* protocols should be an optional capability for consumers that can support it and never a mandatory requirement.
• Consumer-driven contracts (the Einstein approach): Forcing a single set of contracts across all consumers is not always a wise decision. That approach makes consumers dependent on aspects of the contracts they might not be using. It also ties the evolution of the consumer application to the evolution of the contract itself. Having a more consumer-oriented contract approach on which consumers interact with contracts that contain the specific elements that are relevant to their scenario facilitates aspects like versioning, policy control, etc. We often call this the Einstein approach to service orientation in which every consumer has its own view of the universe instead of a Newton approach in which all the consumers share a single view.
• Versioning Strategy: Internet Web Services APIs are subject to evolving given the dynamic nature of the Internet. Keeping multiple versions of the Web Services doesn't force clients to migrate to a new version that doesn't bring any value to them.

Conclusion
This article has explored some of the key challenges in achieving Web Services interoperability in real-world SOA deployments. It detailed best practices and techniques architects can apply to enhance the interoperability of an SOA solution. The complexity of SOA standards is by far the key factor that affects the interoperability of Web Services. Overcoming that complexity is an exercise that involves best practices throughout the entire solution lifecycle. Designing interoperable services facilitates their use in other SOA solutions such as service orchestration, composition, or governance.

Aligning the Path for Service Orchestration & Composition
Achieving interoperability is a key requirement for service orchestration and composition. During the last few years the industry has produced several standards and technologies for service orchestration and composition such as Web Services Business Process Execution Language (WS-BPEL), Service Component Architecture (SCA), and the Web Services Choreography Description Language (WS-CDL). All of those standards are based on coordinated interactions between different Web Services endpoints. However, Business Processes and Composite Services are only as good as their capacity for interacting with different services developed on different technologies. Implementing interoperable services guarantees that those services can be used as part of orchestrations, choreographies, or composite services to address more complex scenarios.