|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