Approaches to interoperate java libraries with .Net application
Following can be the way to interoperate java libraries and .Net.
Following can be the way to interoperate java libraries and .Net.
- In-proc Approach
The In-proc approach works by bringing together the .Net VM and Java VM into one process. The Java procedure calls .Net procedure via common area, like shared memory or through a communication channel. This approach is very efficient and optimized, but very complex underneath.
1. Dynamically linking of Java libraries into .Net application.
IKVM.NET is an ongoing open-source project that translates Java bytecodes to MSIL as needed at runtime. IKVM.NET should allow any Java code to run on the .NET platform.
- Open source project, available free of cost even for commercial usages (As per license agreement)
- The most developed 3rd party API for Java-.Net interoperability.
Cons:
- We need to test it thoroughly, as the project is still under development.
- While online community support is available, there is no commercial support.
2. JNI.NET (http://caffeine.berlios.de/site/index.html)
- This is also an open source project, freely available.
- We can consider this one among In-proc call, as its Beta version release is more promising than IKVM.NET.
- Its architect is different and less complex as compared to IKVM.Net.
- The beta version was released in 2004, so need to check if it works fine with Java 5 features.
3. CodeMesh JuggerNet (http://www.codemesh.com/) and JNBridge (http://www.jnbridge.com)
This is a commercial product with similar functionality to JNI.NET.
- Out-proc Approach
The Out-proc approach allows two different processes talk with each other through a channel understood by both the system. E.g. Java and .Net can communicate together using xml messages.
1. Webservices
Web services are intended to provide a standards-based mechanism for allowing cross-platform components to interoperate.
- Web services are designed for loosely coupled interactions that are infrequent and coarse-grained: therefore they're not appropriate for applications that require frequent and fine-grained calls between Java and .NET classes.
- If you need to expose a rich interface for a large number of Java classes and objects, or you need to allow the .NET client process to create Java objects through the standard constructor (new) mechanism, Web services won't work.
- Web services use a SOAP-based communications mechanism that's inherently slower than alternative binary communications mechanisms.
- Web services are also not well-suited for passing custom objects between Java and .NET as parameters and return values.
- RPC (Remote Procedure Calls) with CORBA
The CORBA architecture provides us with common platform for remote procedure call between heterogeneous systems. However the java implementation of CORBA is freely available, very few .Net implementation are available.
- CORBA for .Net functionality is commercially available through MiddCor from MiddTec.
- Remoting.Corba (http://sourceforge.net/projects/remoting-corba/) is an open source project that aims to bring CORBA to .NET. It's still in beta phase.
- Using a shared database and messaging queue
This is a workaround alternative for designing applications in .Net and Java, which works together. On a broad level, one process put data/object into a middle layer (a database or messaging queue); while other process consume the data and vice-versa.
- The approach is one of the simplest, but may not be suitable in many cases.
- Requires additional middleware system, which will incur additional cost.
- Other Approaches
- Using Visual J#
- .NET supports development of systems using multiple languages concurrently. One way to support Java/.NET interoperability is to translate the Java code directly into .NET's MSIL (Microsoft Intermediate Language) rather than into Java bytecodes.
- Unfortunately, J# a significant limitation: it's legally limited to the Java supported by JDK 1.1.4 plus JDK1.2's collection classes. When the Java code you need uses more advanced features, including just about any J2EE feature such as EJBs or servlets, J# isn't a good choice.
Contents are compiled from different resources. Respective copyrights are acknowledged.