The two most popular managed environments (the JVM and the CLR) are in fact, nothing more than a set of shared libraries, each providing services to executing code such as memory management, thread management, code compilation (JIT), etc. Using both the JVM and the CLR inside the same operating system process is easy; in this new article, Ted Neward shows how and why.
Read In-process Interoperability
In the article Ted shows how to create a JVM inside a CLR process the old fashioned way and also how to use tools such as JACE, IKVM and JuggerNET to do two way interop more easily. Ted concludes explaining why this kind of interop may make sense:
Read In-process Interoperability
In the article Ted shows how to create a JVM inside a CLR process the old fashioned way and also how to use tools such as JACE, IKVM and JuggerNET to do two way interop more easily. Ted concludes explaining why this kind of interop may make sense:
Overall, it may seem less-than-obvious why in-proc interop is even on the table of possible approaches; aside from an obvious speed advantage (in that moving data around in a single process is far, far faster than moving data across a network, even a fast gigabit one), a number of other advantages include:
- Centralization. In many cases, we want certain resources (database sequence identifiers generated within code, for example) to be inside of one-and-only-one process, to avoid complex synchronization code between processes.
- Reliability. The fewer hardware tiers involved, the less vulnerable the entire system is to a single machine outage.
- Architectural requirements. In certain scenarios, existing architectural requirements will mandate that all processing take place inside of a particular process; for example, the existing user interface for an application may already be coded in ASP.NET, and the interoperability part of the application is to drop a message into a JMS queue for an EJB message-driven bean to process. Sending the message out-of-proc to a Java service that simply drops the message into a JMS queue is a bit redundant and expensive, particularly given that JMS client code is typically straightforward. Putting the JMS client code inside the ASP.NET process (Codemesh offers a specialized version of JuggerNET proxies specifically for JMS client scenarios) offers the simplest way to keep with the "flow" of the existing architecture.