JuggerNET bridges Java and .NET for health care |
 |
By Nitin Bharti, News Editor
07 Apr 2005 | SearchWebServices.com |
|
|
Web services are not the only option when it comes to Java and .NET interoperability. IDX Systems Corp., a provider of software for the health care industry, found an easier way to make the two platforms talk to one another.
The Burlington, Vt.-based company needed to get its product, which is based on an enterprise Java architecture, to interoperate with .NET clients. The product is a Java-based Web application that provides 138,000 physicians, 500 hospitals and 800 medical groups with clinical, administrative and financial information.
|
|
|
|
|
There are times when the performance of SOAP-based Web services is insufficient. So other, more native, solutions still have a play in the market.
Randy Heffner
Vice President, Forrester
|
|
|
|
|
|
|
|
|
|
Rendering its Java components as Web services was not a practical option as the company would've had to expose too many application programming interfaces (APIs). Additionally, many of IDX's customers were developing Visual Basic (VB) applications to interface with the product, so IDX needed a more efficient way to get its clients' .NET applications to talk to its Java middleware.
To solve this problem, IDX chose JuggerNET, an integration tool that takes compiled Java code and generates C# source code. With the generated C# code, IDX's VB customers could develop applications that seamlessly call IDX's Java code as if it were a .NET language.
"As far as the server is concerned, it's really talking to a Java client," said Alex Krapf, president and co-founder of Carlisle, Mass.-based Codemesh Inc., the company that created JuggerNET. "Under the hood [of JuggerNET], we have an integration layer that uses P/Invoke and JNI [Java Native Interface] to delegate from .NET to the JVM [Java Virtual Machine] in the same process."
Based on the published Java APIs, JuggerNET generates .NET types that look very similar to the corresponding Java types, Krapf said. The tool takes the Java archive file that is deployed on the client side, generates .NET bindings and compiles it into an assembly, which appears as .NET native types to VB, C# and other .NET programmers.
Web services, however, were not totally out of the picture for IDX. In addition to using JuggerNET as a Java to .NET bridge, it also implemented a suite of Web Services Description Language-based Web services that are implemented in .NET.
"Basically, we are using .NET to front end our Java product with Web services," said Sasson Havusha, director of development at IDX. "Given the advanced Web services support in .NET, we found it much easier and cheaper to use .NET to host Web services."
In addition to making Java classes accessible from .NET, JuggerNET also enables the integration of .NET applications into any JMS [Java Message Service] messaging environment, the implementation of servlets using .NET languages and the creation of Java interfaces implemented in .NET.
The many flavors of interoperability
JMS to MSMQ bridging, enterprise application integration, and protocol conversion technologies are some alternatives to connecting Java and .NET.
"Protocol conversion technologies operate either 'on the wire' [e.g., .NET code makes itself look like Java code at a network level or vice versa] or via more tightly bound technologies that make the conversion in memory," said Randy Heffner, vice president of Cambridge, Mass.-based Forrester Research Inc.
Web services can provide a sufficient approach for many different inter-application communication scenarios. However, there is often a trade-off between performance and interoperability.
"There are times when the performance of SOAP-based Web services is insufficient," Heffner said. "So other, more native, solutions still have a play in the market."
|
|
|
|
