s we head into 2004, for me it's a time to reflect how far our industry has evolved over the past twelve months, and the pace at which new technologies and ideas are introduced. During the past few years, organizations recognized both the need and the benefits of the .NET and Java platforms, recognized that each has specific costs and benefits, and built applications that run on both. Not surprisingly, given that mix of platforms, they're now finding an increasing need for interoperability, and are starting to consider the best approach for achieving that interoperability.
Interoperability through Web services has received the greatest amount of attention, and in this last year we've seen many advances in Web services stacks from both Microsoft and many Java vendors. However, Web services are not the only option to create an interoperability solution. Other options exist that provide interoperability through means other than Web services. These include numerous third party solutions, asynchronous interoperability using databases, and the use of message queues to relay messages between the two.
Despite all of this new technology and many articles and publications on the subject however, many customers are still unsure which interoperability option they should select. Should they strategically invest in developing applications that use Web services, or instead select a more tactical option that's more inline with technology they're already using? What are the performance costs of each option? Should they align their options with the major platform vendors or instead invest in other third party solutions?
This series of articles on the subject uncovers and presents options that exist today to achieve bridge the gap between Microsoft .NET and Javainteroperability using Web services, binary communication, CORBA and resource tier solutions. For each option, you'll see typical scenarios in which the technology can be applied, and weigh up the pros and cons to help address questions and concerns when selecting a technology for use in your own environment.
If you were to take the industry as a whole in 2003, it would be fair to say that Web services have been a cornerstone for almost every major vendor's line of products. The foundation of Web services in the Microsoft platform continued through the release of v1.1 of the .NET Framework and support for Web services Enhancements (WSE) v1.0 in 2003. IBM continued to increase Web services support through the WebSphere 5.x platform and their Emerging Technologies Tool Kit (ETTK), an AlphaWorks release. Other major J2EE application vendors also strengthened their support for Web services, and even smaller vendors underwent some changesthe most notable of which are webMethods acquisition of The Mind Electric towards the end of the year.
Given this rich landscape of support for Web services, you may be wondering if and how all the vendors ensure that their implementations play well with others. This is the job of the Web services Interoperability Organization, more commonly known as the WS-I . The WS-I is a consortium of over 170 vendors, system integrators, and enterprise customers with the overall goal of ensuring and promoting Web services interoperability throughout the industry. 2003 was a notable year for the WS-I because it marked the release of the 'Basic Profile 1.0', a documented profile of exactly what it is that makes up a Web service. For v1.0, this is a set of existing specifications (SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, XML Schema and HTTP 1.1), tied together with a set recommendations outlining the role of each standard and the resolution of many potential interoperability issues.
So, given this huge industry momentum, the flexibility and extensibility of SOAP and the ubiquitous way in which Web services traverse both firewalls and proxy servers, you may ask: Why is there a need for any other interoperability solution apart from Web services? The answer typically lies in what Web services cannot achieve today.
Data passed using Web services inherently depends on XML and XSD. Web services pass SOAP messages encapsulating this XML data to another party using HTTP. For interoperability between .NET and J2EE, this can perpetuate two potential issues.
First, serializing data from in-memory objects to XML can be relatively expensive, both computationally and for the resulting size of the data. Taking large objects and converting them to an ASCII based XML representation canin some casesproduce large documents. When you're passing a single message or document across a network each day, that's unlikely to be an issue. If however, you need to send thousands of messages per second between two systems; the additional overhead can be a consideration.
With that overhead in mind, I think there is also an element of perception of overhead to this argument. Many arguments against Web services start from the point of view that translating objects into XML, creating SOAP messages and sending them across HTTP is always going to be slow, often to the point of being unusable. Some organizations have even refused to adopt any Web services strategy for exactly this reason. My advice? If that's your concern, prove it. Take data that is representative of your needs and build a proof-of-concept application that passes that data between platforms using Web services. With the advances that have been made in both Web services stacks and XML parsers, many who try this are surprised at how efficient modern Web services are.
The second issue with Web services and interoperability is the HTTP protocol itself. With little doubt, HTTP is the most universal protocol in use for Internet technologies todayand for many applications HTTP is the perfect transport for Web services. HTTP however, is a request-response style protocol. The client makes a call, and expects a response within the lifetime of the call. Some applications instead need to work within an asynchronous modelfor example a loan or credit card application process may take several hours to complete, and it doesn't make sense for the client to hold open the call channel for that duration.
Applications today normally overcome this type of 'asynchronous call' by having the client regularly poll the server to see if a requested operation has completed. While polling works, it's inefficient, and those inefficiencies sometimes demand other transports to return data to the client. Another transport, for example, could be a TCP channel that the client can listen to, or the server could even return the Web services response as an SMTP message (what better proven way to send a message back to a client?).
While this is all possible within the model of Web services, most implementations today support only HTTP. Other transports are gradually starting to be recognized and adopted, but this will take time.