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.

Microsoft’s Dino Chiesa gently takes IBM to task for some aspects of its WebSphere Service Registry and Repository. His take is that connecting to it requires tightly coupled approaches. He wonders if IBM were to unilaterally create WSDL/SOAP interface for IBM WSRR, if that would not qualify as “an IBM-defined protocol, an IBM-defined schema, an IBM contract.” But, of course, he is representing, Microsoft, and that could color his analysis.

… MS Office defines a WSDL and Schema for any Research Service. It is interoperable, and I have shown Java apps acting as Research Services for MS Word 2003. But the interface itself is non-standard. That is to say, Microsoft defines it unilaterally.

Somehow that situation seems ok, while the situation with IBM defining the interface for its SOA Repository seems inappropriate. HAhahahaha! I find this very challenging terrain to travel over. (I understand my view here may be due to a biased perspective, but I am trying hard to guard against it.) The Research Service interface for MS-Word is a feature of the product. MS Word was not designed to be the center point of a SOA infrastructure, as would a SOA repository. MS Word can best be thought of as an endpoint or end-node in a SOA mesh, and the research service interface is just one small artifact that affects that end-node, not the entire mesh. Furthermore, the Research Service interface is small and simple, in comparison to the richer interface you’d need for a SOAP repository. Because of all this, the MS-Office Research Service interface need not be an internationally sanctioned standard, while it seems to me that because a SOA Service Repository does play that central role, and is a much more complex service, it ought to have network interfaces that are based on multi-vendor standards. Is this hypocrisy? I don’t think so.

Read the rest of the story .. Tell us what you think.
WSRR and Interop - on All About Interop Blog