In-Depth

Integrate Java and .Net

Both major platforms push Web services as a means of integrating applications across platforms. Check out another alternative that tightly integrates Microsoft code with Java apps.

Given the potential for breaking new ground in business intelligence and analysis, application integration remains the elusive goal of many development and application customization efforts. Applications were typically developed or purchased for specific uses; yet as time passed, enterprises found that combining data or results from some of these applications could offer measurable efficiencies. In some cases such combinations could go even further, creating entirely new lines of business or business processes.

I've written about several ways of achieving application integration. Among the best known are Web services, adapters, messaging, and data transformation. Let's review them.

Web services is a standard and popular technology for encapsulating specific processing functions within a self-contained component that has known lightweight calling conventions. They provide a mechanism for retrieving data from one application, perhaps processing it in some way, and sending it to another.

Adapters deliver native connectivity to leading enterprise-packaged applications, legacy systems, mainframes, databases, and Web technologies. Adapters may also be referred to as connectors, depending on the vendor supplying the technology and the applications being integrated.

Messaging uses a standards-based message broker to link data between two or more applications. A message broker allows applications to deliver high-reliability, asynchronous messaging for event-enabled data flow inside and outside of the enterprise. Messages are discrete packets of data that can be sent serially from one application to another, and are typically processed as they arrive. Messages can also be queued before they are processed, and accepted in turn, or ordered, in some way.

Data transformation allows you to visually translate between XML and non-XML messages, including legacy formats. This type of implementation can be a part of a Web services architecture, or it can stand on its own in a non-Web environment. The value of this approach is that it enables you to use XML for defining and storing different data formats in a lightweight and flexible manner, without the necessity of setting it up as a service-oriented architecture (SOA).

These approaches to integration might be considered to be coarse-grained, in that each application, or at least major application component, is still on a separate and distinct platform—which isn't a bad thing. However, it does limit the options available in making application data and processing available.

Room for Everyone
I've since discovered yet another way of performing integration—specifically, integration between the Microsoft and Java platforms. This kind of integration is of particular interest to me because I am platform agnostic in my core beliefs. I think that each platform has its merits, and the selection of one over another should not be made on absolute grounds, but rather on the specific advantages and limitations for a particular task or development project.

Others might have other reasons for wanting to integrate components from both Microsoft and Java platforms. Nevertheless, I've heard from an increasing number of enterprises and industry analysts that being able to seamlessly integrate Java and Microsoft code directly into applications is increasingly becoming a priority.

Why? Although individual development teams are not likely to work on both platforms, the larger enterprise will have a need to take the efforts of multiple development groups and make them work together. The question is, how closely together do these components need to work? Microsoft and the major Java vendors will claim that Web services provide a satisfactory level of integration.

And in some cases this is no doubt true. A lot of the buzz about integration is really about making it easy to get data from one application to another, but while data transfer is an important aspect of integration, it's not the only one. Integration can also mean business logic, for example. It may make sense for one application component to hand off an intermediate processing step to another, if that second component performs a useful function for both application uses.

Credit processing is a good example. One application might need to do a credit check on an application as a part of the process of granting credit approval, but data from that same credit check is used to determine the interest rate charged on the loan. Rather than run the credit check twice, it makes sense to share this bit of business logic across the two processes.

When we talk integration, therefore, we can be talking about a lot of things. What we usually aren't talking about is integration at the code level. Typically, individual development teams work on a single platform, and rarely, if ever, do they have the need to integrate code from both the .Net and Java platforms. However, that characteristic isn't true in general for the enterprise, which often has the need to share functionality among different applications, regardless of the platform.

In support of this goal, the approach that I've come across appears to be unique in its ability to tightly integrate Microsoft code within Java applications. It does so by turning .Net code into Java, so that the entire application is deployed as a Java application.

In a nutshell, Visual MainWin from (Mainsoft) takes .Net Intermediate Language (MSIL, which is similar in concept to Java bytecode) and translates it to Java bytecode. It also packages it for deployment to the appropriate application server. It comes with JBoss, and by default it will deploy to that specific server.

There and Back
Watching it in action is interesting and instructive. Visual MainWin is a plug-in for Microsoft Visual Studio that operates seamlessly within that development environment (I used it with Visual Studio 2003). When you build, it creates the MSIL, and then adds an additional step to translate it into bytecode and package it in the appropriate way for execution.

Once you have completed the build process, you can use the Visual Studio debugger to debug this application. Such debugging might make sense, until you realize that the application is in bytecode. How does this debugging work? When you invoke the debugger, it translates the bytecode right back into MSIL for the debugger. This behavior also means that you can practically use a full range of Microsoft developer tools in the building of a Java application.

As you might expect, the conversion from .Net's MSIL to Java bytecode isn't perfect. The imperfections have less to do with the Mainsoft translation process than it does with differences in the underlying platforms. For example, exceptions from the .Net platform are derived from the System.Exceptions class, but that's not the case with Java. In Java there are two possible classes, depending on whether the exception is raised from the application or the underlying Java Virtual Machine (JVM): java.lang.Exceptions versus java.lang.Error. When .Net code is translated into Java bytecode, there is no way to catch java.lang.Error exceptions.

This imperfection is a relatively minor issue. If you really need protection from java.lang.Error exceptions, you can write exception-handling code in Java and package it with the application after it has been translated into bytecode. In most cases it probably isn't even necessary to catch those exceptions.

Visual MainWin's approach to application integration isn't for all application development efforts. Specific conditions should be met before a development team considers this integration method: an existing code base in .Net, but the desire or need to support Java development; Microsoft expertise, but a mandate or other reason to build and deploy Java applications; and a need to integrate Microsoft and Java components into the same application.

Mainsoft representatives have described several of these types of uses to me. For example, one customer had an enterprise mandate to build applications in Java, but had Microsoft skills and a deadline to meet. Because enterprises often make the decision at the CIO level to throw resources behind one or the other platform, Visual MainWin represents a way of achieving those directives more quickly and without substantial amounts of retraining.

It is this last condition that makes for an intriguing application integration alternative, however. A .Net component that needs to be used by a Java application can be made available in several ways, but let's consider two: either as a Web service or compiled to bytecode using Visual MainWin. The Web service makes the logic available in a single form for multiple applications at the expense of setting up the Web service structure (building the SOAP listener, performing any data translations required, and so on).

Added Value
The alternative is to simply take the .Net source code (presumably organized as a Visual Studio project), and compile it over to Java code and integrate it with the rest of the application. This option makes the integration seamless, and probably higher performing, but it doesn't make the component available to other applications.

There is no correct choice; it depends on the unique characteristics of the situation. But Visual MainWin provides an alternative that will be attractive technically and functional under many circumstances. And that's what application development is all about—having choices and making the best ones for each circumstance.

Integrating applications and application components is often the primary way of getting additional value out of existing software. With both major platforms pushing Web services as the integration strategy of choice, it's good to know that there are alternatives. And this particular alternative is more than unique technically; it's also useful and easy to accomplish.

Most   Popular