Beyond Web Services, a look at bridging Java/.NET apps

By Jack Vaughan
Interoperability concerns gained a new tenor a few years ago with the advent of Java, XML and .NET. Among the companies that arose as a result is JNBridge, which makes the JNBridgePro Java and .NET interoperability tool. This over-the-wire approach is far removed from XML Web services, although JNBridge does support SOAP-based approaches among its deployment options.

However, there is a real effort here to formulate an approach that  ‘lets the Java do java,  and the .NET do .NET.’

In effect, JNBridgePro builds its bridge by generating a set of proxies that expose classes’ APIs and manages communications between .NET and Java classes.

JNBridgePro 3.1 came out last month, supporting new capabilities that allow Java GUI controls to be embedded directly in .NET applications, or .NET GUI controls [including WinForms] to be embedded in Java apps. Also last month, the folks at JNBridge joined the Interop Vendor Alliance,  a group whose august ranks include no less than AMD, BEA, Microsoft, NEC, Quest Software, Sun Microsystems, Symphony Services, and others.

JNBridge’s approach is to enable developers to access Java objects and classes from .NET as if they were .NET objects and classes, or vice versa. JNBridgePro exposes objects, classes, members, or user interface components across the confines of the individual platforms.

Take it to the bridge
TheServerSide Interoperability Blog recently spoke with Wayne Citrin, JNBridge founder and CTO to get a view on interoperability today. From the get-go, he said, Citrin and his colleagues saw areas in interoperability that big vendors were unlikely to cover. And, while there was a lot of XML-oriented Web services standards committee work going on among those big vendors, JNBridge was among a set of vendors that looked beyond a XML solutions.

“I was talking to a number of people around the time that .NET came out. People were asking would [.NET] work with their EJBs [Enterprise Java Beans], said Citrin. The answer, of course, was ‘not really.’

Meanwhile Web services were posed as something of a Silvr Bullet. They were not every programmers favorite, however, and few denied XML Web services could create system overhead. In some apps, that overhead was foreboding.

Tied to text
Web services are ‘tied to text messages - tied to ASCII, and ASCII is very verbose,” said Citrin. “You throw in XML and these extra words and constructs.” That is one problem with XML.

“The whole service-oriented approach is really very narrow,” said Citrin. “You are, by design, exposing a narrow view - like peaking through a keyhole. What happens is that developers and customers sometimes really want to access an API, not a service.

“You have rich APIs like EJB or JMS. They are complex. These are not just a single service that you just access.”

Citrin aggress that it is not just a black and white picture, and that Web services have their places. “Web services are very useful for a lot of things,” he says, “it’s easy to  them put together and have them find each other. But they are not big on states. They are not big on references.”

Despite a massive push toward “SOA,” the fact may remain that developers and even their managers aren’t thinking about services. “A lot of people don’t want to think about services, said Citrin. “A lot of times what is offered on the other side isn’t a service. What you want is to get object references back, call backs, and exceptions - things that programmers do every day.”

“Developers want to access their Java code from .NET, or vice versa,” he summarizes.
Some useful related bridging links
A view on in-process to cross-network bridging
A view on in-process to cross-network bridging, cont.
A JNBridgePro architecture diagram
JNBridge blog

7 Responses to “Beyond Web Services, a look at bridging Java/.NET apps”

  1. Max Kington Says:

    I don’t think the fundemental problem is the metaphor. With a mechanism for moving data anyone could provide those “things that programmers do every day”. What people really want is a binary protocol so they can feel all warm and fuzzy about it skipping along at warp speed and not being so “tied to ASCII”.

    What I could do with is CORBA, which is as easy to use, understand and administer as WebServices with similar quality of tool support.

    CORBA did an excellent job of the mapping, all the way from endieneness to logical Object abstractions. However, as anyone who has ever had to use CORBA in anger will tell you the tools were terrible, the vendors runtimes buggy and in an effort to universally solve this mapping problem it was hugely complex.

    WebServices have, through good tool support and the simplicity of the underlying transport (I think most people when they got into webservices did it over http, even if these days people are putting more envelopes on message buses), taken off, people use them. But the simplicity and clarity is an overhead, run a webservice endpoint and profile how much time is being spent marshalling and demarshalling the XML. For some applications I’ve worked on it’s crippling, IBM buying DataPower was a shrewd move.

    If you want to have a go at building a simple interop library, port Java DataInput/OutputStreams to C# (the source is now GPLd), that takes about 20 minutes. Then decide that you order your attributes alphabetically and write them to the stream, remember you have a way of sending all the primitive structures (and Unicode strings). At this point there is nothing stopping you from reading this data back into a set of C structs, if you understand the order of the stream. In your OO language of choice the next thing is identify the object you rehydrate your serialized representations into, use a class name, a version number, whatever you like.

    There are standards for bytes which you can layer ontop of these things on a case by case basis, need IEEE-754 number representations? Use it.

    Last but not least, throw in a code generator, (have a look at GRAM) to get from one source representation to another.

    Job, as they say, is a good’en.

  2. Peter Abramowitsch Says:

    Just a reminder that Intrinsyc’s JA.Net has been providing this same functionality for several years now.

    We have a large hybrid desktop app (Java and DotNet) and marshal xmlized business objects through the bridge bidirectionally. Since it’s all handled between processes on the client machine, the overhead of the bytestream version of the object is nil and response time is instantaneous.

    There are many ways this bridging can be deployed but we’ve chosen serializarion via xml so that the bridge is only used for native data types like string or long. JA.Net is also capable of serializing and unserializing data structures, but there’s more overhead with complex recursive object graphs if you approach the problem generically as they would have to do.

    - Peter

  3. avi Says:

    Did you look at the price page?

    instead, try ice library from: .zeroc.
    it is: free parallel and cross platform.

  4. Jack Webb Says:

    I sort of gave up worrying about overhead in the past. So many times the hardware caught up with the new bloated [object] software. But maybe with Web services and verbose XML the pendulum is turning. Many apps, I would think, cannot afford a hardware accelerator - which is what I understand IBM’s DataPower box to be.

  5. Vitaly Says:

    Some people say Java/.NET interoperability can be based on Web technologies:
    • Quality of Service – WS-Reliable Messaging, WS-Coordination, WS-Transactions
    • Security – WS-Security, WS-Trust, WS-Secure Conversation, WS-Security Policy
    • Metadata – WSDL, XML Schema, WS-Policy, WS-Metadata Exchange
    • Messaging – SOAP, WS-Addressing, Message Transmission Optimization Mechanism (MTOM)
    The purpose of this interoperability type is supporting common protocols and means to interface Java and .NET systems (like J2EE, BizTalk, etc.) in MS Windows or other OS types. This approach is useful for development products based on existing WEB or Application Severs (e.g. composite applications). But it does not good enough in use of legacy Java and .NET codes used in development new products and standalone applications when embedding of Java-to-.NET or .NET-to-Java needed.
    I found articles where written that sometimes enough only resource (or data) interoperability. There are two known resource interoperability: memory and database. Such interoperability implies availability of some mediator, which supports access to the common resource (memory, database).
    What suggests Jack is the Java/.NET interoperability based on bridging. Here you can use JNBridge, j-Integra (based on CORBA), COM Bridges that use option of conversion .NET modules to COM modules, etc. And here I agree with Jack that ‘lets the Java do java, and the .NET do .NET.’ Everything done in Web interoperability can be implemented with bridging and Java part interacts through Web with Java, .NET code interacts through Web with .NET.
    I agree that “Developers want to access their Java code from .NET, or vice versa” but bridging is a huge overhead. Maybe be better to have some JNI SDK but for .NET. Having it we can develop tools that automate JNI code writing by generating Java class wrappers in .NET. Our company issued Object-Oriented JNI SDK for .NET . Why Object-Oriented? Because .NET is object-oriented and some part of regular JNI for C/C++ can be simplified by making simple classes: JClass, JObject, JString, Java array classes (to handle all type Java arrays including multi-dimensional), etc. that hides the most routine code written to convert jstring to/from String, creating and deleting Java references, tracing thread contexts while use of JNI methods, etc.

  6. mike Says:

    please try also IKVM (convert jars to dll etc.)

  7. Vitaly Says:

    IKVM is mimicry to Java but not a Java technology.

Leave a Reply