No web services for Java and .NET interoperability?
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.
April 5th, 2007 at 1:53 pm
In most articles on Java/.net interoperability authors focus only in Web means used to integrate Java and .NET modules. Others suggest using some mediators like CORBA and various sorts of Java/.NET bridges. But no one discusses option of in-process integration Java code with .NET. This can be done by substituting regular JNI with JNI for .NET – Java native modules should be written in any .NET language. Where Java native methods are implemented with .NET methods, .NET JNI should hide all low-level calculations with Java references, memory allocation, Java error processing, etc.
April 5th, 2007 at 6:23 pm
Although I see your point that web services may be used as solution to problems arising from old legacy applications somewhere running in the organisation, I cannot quite agree with your point.
In those scenarios you are absolutely right and there are for sure numerous obstacles. But I believe you miss out the large number of applications which are designed from scratch and are supporting interfaces to access or export data from outside the application’s boundaries.
I have worked quite a lot on these kinds of projects lately and I find it a great way to build interfaces to your applications and consider the exact implementations of any other application accessing this data/interface later.
It also easily enables the cooperation of multiple companies (assuming that the choice for one language/platform is usually more or less fixed within a single organisation and since no interop problems would arise). However accross different companies the choices might be very different and a soap based interface between different parts of the n-tier enterprise solutions leave a great deal of flexibility to all participating members.
To summarize, also from my recent past experience, soap does play a vital role in Java and .Net Interoperability and not only for old legacy apps.
April 9th, 2007 at 5:59 am
maybe web service is a obstacle of SOA. The service provider should only know the interface, and provide an implementation for it. they don’t need to provide the method(web service etc.) to access it.
for java and .net, there will be a container to glue them。 the java and .net are executed in the container.
May 2nd, 2007 at 8:01 am
People are cunning when say that SOA technology developed for Java/.NET interoperability. They forget to be precise. The SOA technology may be useful only for J2EE/.NET interoperability, i.e. for Server based products and for nothing more.