For someone who has not been involved till now in any solution development which requires interoperability across web services developed on different platforms, it’s quite easy to believe that he/she can use web services specifications to achieve the required interoperability. Because web services specifications and standards have been developed to get interoperability – so when one uses them, he should achieve it.
Unfortunately that’s not true. As far as the basic web services standards such as XML, WSDL, SOAP etc. are concerned, software vendors have been able to make their products interoperable to a great extent because of wide adoption of the WS-I’s Basic Profile. However, when one feels the need of advanced functionalities such as security, transactions, reliable message delivery in web services – many vendors are providing this through WS-* specifications such as WS-Security, WS-ReliableMessaging (WS-RM), WS-AtomicTransactions (WS-AT) etc. But when one needs to interoperate between web services being developed on different platforms using WS-* specifications – life is not that easy.
One might need to take care of many aspects. Even then, achieving interoperability might not be possible in some contexts. So whenever someone is designing a new solution that involves web services across different platforms – he need to provide special attention to selection of platforms and the way the solution is built.
I have recently worked on a project that involved three different platforms: Microsoft Windows Communication Foundation (WCF), BEA Weblogic Server and IBM Websphere Application Server and uses many WS-* specifications: WS-Security, WS-Federation, WS-RM, WS-AT. The experience was not very good as there was lot of tweaking and changes that we had to make to get different web services interact with each other; however we also learned quite a few lessons. I’ve documented these lessons in my recent article that is published in SOA Web Services Journal. You can read the article at the following location: