By Daniel Rubio
[Posted by Jack Vaughan]
Though the web services stack - SOAP, WSDL, WS-* and Co. - will continue to be the preferred choice on which to build Java and .NET applications in order to guarantee interoperability, on many fronts, web services may not even be an option for many, for reasons ranging from the technical to the organizational.
Lets face it, most interoperability projects arise from an “old Java” or “old Visual Basic” application trying to communicate with a “new Java” or “new .NET” application, those cases in which you have a clean slate for building a from scratch “web services enabled” application are few and far between, which takes us to the question: Is it really that difficult to make web services work with an “old Java” or “old Visual Basic” application?
Besides the obvious learning curve inherent to any technology, web services also come with a series of technical pre-requisites which have to be fulfilled and, often, organizational impediments which have to be overcome prior to being used.
Do you have unfettered access to an application and its source code? Technically speaking, web services generally imply deep code inspection, take the case of WSDL generation , which is the norm for describing web services logic and is needed to describe an application’s methods and fields. While it might be easy to generate a WSDL contract from a pilot application on your workstation, it might be quite another to get one from a 24×7 human resources application which is considered a “black box” that just works.
Still, let’s assume for a moment you have access to any piece of an existing application’s logic, and your technical prowess in web services is at such a high-level that no technicalities will deter you, then ask yourself, has your organization bought into web services? This may seem trivial, but is equally important than many of the technical reasons behind adopting web services.
Technology decisions in any organization are a strange mix of economics and politics, it generally involves many people, ranging from end users, executives to vendors. As Geoffrey Moore’s work in Crossing the Chasm points out, the technology adoption life-cycle - for which web services is surely no exception - is characterized by various groups: the innovators, early adopters, early majority, late majority and laggards.
Considering web services’ short life, it would be safe to assume many companies actively using web services are indeed innovators or early adopters, but does this mean interoperability has to take a back-seat for those still out of the web services adoption life-cycle? Absolutely not, it simply indicates other means are being used.
In the next series of entries, we will take a look at other approaches used for achieving Java and .NET interoperability without the use of web services, from messaging, CORBA to JNI, and will you get a feel, for ‘the old-guards’ if you will, of what is behind application interoperability.
Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at http://webforefront.com.