WorldWind.NET Technology

On this page we're going to delve a bit deeper into the technologies that underpin WorldWind.NET.

Let's take a look at the architecture of an integrated solution. The image below shows the anatomy of an integrated application.

The first thing we want to point out is that the this is one process: all of the components you see above are running in the same process and communicate with each other via in-process function calls. On the left you see the JVM. The JVM is loaded into the .NET process via the JNI Invocation Interface. It is configured to load the WorldWind types and, optionally, your own custom Java types.

On the right you see your own .NET application code. It communicates with the WorldWind APIs through the proxy types that closely resemble the underlying Java types in usability. The proxy types in turn rely on a managed runtime assembly (netrt) and an unmanaged runtime library (xmogrt) to handle the integration with the JVM.

At runtime, the WorldWind.NET proxy types delegate all calls to the managed runtime assembly. It in turn delegates to the unmanaged runtime library via P/Invoke, .NET's native escape hatch from the world of managed code. The final handoff to the JVM is achieved via the Java Native Interface (JNI).

That seems to be a lot of steps but each one is pretty fast and in practice, our customers have never experienced performance problems.

Now let's look at some .NET code that uses the WorldWind.NET proxy types.

That code should look incredibly familiar to anyone who has used WorldWind in Java.

Your .NET developers can be productive WorldWind users in a matter of hours.

Fastest Possible

At runtime, all these calls happen blazingly fast when compared to alternative integration approaches. JNI has a poor reputation when it comes to reliability and performance. Yet the fact remains that it is the fastest way of crossing the language boundary by far. By using a proven and tested runtime library and generated code to invoke the Java Native Interface we also make sure to obey best practices and avoid many of the performance traps and all of the memory leaks and crashes that plague hand-written JNI code.

Most Secure

The in-process nature of the integration also means that you do not have to worry about new security vulnerabilities due to the integration. There are no ports to be opened, firewalls to be configured, or certificates to be installed just to secure the integration solution. As long as you take a little bit of care with your runtime configuration, your threat profile is essentially the superset of a pure native application's and a pure Java JDBC application's threat profiles.

Mature Configuration Framework

The Java Runtime Environment has many options—classpath is just the best known one—and you might have to use many of them to configure your integrated application's JVM. The JuggerNET runtime offers a mature configuration API that allows you to hardcode settings in your application, use configuration files, pick up settings from the environment, or even from shared libraries when they get loaded.