email article printer friendly

Integrate Java and .Net
Take a unique approach to integration that is technically cool and useful under the right circumstances
by Peter Varhol

February 17, 2005

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.