A well-planned Web Service interoperability environment begins by clearly defining who your Web Service consumers are now and in the future. There was a time not so long ago when you could count on a fairly homogenous consumer population. This was about the same time that you were happy just to be able to get a Web Service running in the first place and finding a consumer who could actually interact with your Web Service was cause for celebration. Those days have changed however and Web Services interoperability, once a "fancy" addition to your SOA design, is now a key and indispensable requirement in most SOA scenarios.

Today, SOA architects must contend with complex scenarios that assume a variety of Web Service consumers or in many cases are asked to create Web Services that are generic enough to be interoperable with just about any known consumer. If you're serious about implementing SOA in your worldwide enterprise you'll have to forget about the luxury of being able to dictate the configuration of all of your consumers and instead build fully interoperable Web Services. Most robust Internet Web Service APIs, familiar to all of us such as Amazon.com, eBay, or Salesforce.com, have learned this lesson already with very successful results. Those companies know that Web Service interoperability lies in the architecture approach and not in the implementation of new middleware.