Top 5 Best Practices for J2EE to .NET Interop

Into 2006, J2EE to .NET interop will continue to grow as a top priority for IT execs. To provide IDN readers with some Best Practices for interop, IDN spoke with execs from Marlabs, a leading interop services firm to the F500. Get the pros and cons on the Top 5 interop techniques, including (1) shared database; (2) runtime bridges; (3) message orientated middleware; (4) integration brokers, and (5) XML-based web services.

Tags: Interoperability, Web Services, Layer, Java, Integration, Abstraction, J2EE,


As J2EE to .NET interoperability continues to become a higher priority for IT execs, a growing number of services firms are gaining first-hand experience in such projects.

IDN speaks with Manjunatha Kutarahalli, Vice President Global Delivery for Marlabs, to understand the pros and cons of using some of the most popular interop approaches, and get an update on the progerss of defining J2EE-to-.NET Best Practices.

"In this space, we hear from our clients that major vendors are not offering enough Best Practices information, they are just defining the standards. So, Marlabs is documenting patterns and Best Practices for interop from our engagement experiences," Kutarahalli told IDN.

The effort is attracting a lot of attention. "Third-parties have to come in as well to help articulate customer problems in a way that vendors can understand. So, for instance, we are trying to tell the vendor how the enterprises is writing the apps itself, and use different abstractions for business logic and app logic and in that way take these pieces and reuse them across a different platform," Kutarahalli said.

Taking Interop from "Here" to "There"
"Today's enterprise applications are built in n-tiers that provide modularity and ease of maintenance," Kutarahalli said. "Business functionality across the traditional enterprise is broken into manageable modules and built using architectural frameworks like MVC (Model-View-Controller) and SOA (Service Oriented Architecture). This n-tier architecture lends itself to create integration and interoperability points," he added.

Marlabs work shows that 5 key approaches to J2EE-to-.NET interop dominate. They are: 1) a shared database; (2) runtime bridges; (3) message orientated middleware; (4) integration brokers, and (5) XML-based web services.

There are a number of ways in which you can implement J2EE to .NET interoperability, Each has particular advantages and disadvantages, and each works in some circumstances but not others

Shared database techniques often involve using some form of database independent connectivity API, such as ADO.NET or Java Database Connectivity (JDBC) to provide a level of abstraction from the database itself (usually SQL Server or Oracle). However, challenges with this technique involve generating an appropriate database schema that all applications can address.

Runtime bridges are third-party solutions that provide interoperability between J2EE and .NET, so that Java classes appear as .NET classes and vice-versa. This allows you to use .NET Remoting as a communication method, with the Runtime Bridge handling the calls to the Java side. The two products in this area are JNBridgePro from JNBridge and J-Integra from Intrinsyc. [CodeMesh's JuggerNET is also in this 'Runtime Bridge' category.]

One could also use CORBA solution from MiddCor. This Object Request Broker (ORB) has been written in C# and connects J2EE with the .Net world. MinCor.NET for J2EE has been developed entirely as managed code and can therefore be accessed by all .Net languages (C#, VB, C ++, etc.).

Messaging offers an asynchronous mechanism for communicating between tiers, often based on MSMQ or IBM MQSeries. Messaging enables loosely coupled operation, particularly where you need more than just a one-to-one linkage between application components and Web services are not suitable. Messaging also supports transactions, security (encryption and authentication), tolerance for network outages, and recorded message delivery. However, messaging does not offer any form of synchronous operation and can cause issues with port assignments and firewall operation.

Integration brokers go beyond point-to-point connections to provide end-to-end integration of applications, enabling the automation of critical business processes across an entire distributed application or enterprise. Typically built on a messaging framework, integration brokers are particularly important in environments that use trading partners within the application solution. Integration brokers also provide prefabricated application adapters, allowing multiple external components such as mainframe or third-party applications to interact with the integration broker as either provider or consumer or both. Some leading integration broker products include IBM MQSeries Integrator, CommerceBroker, and Microsoft BizTalk® Server 2004.

XML, Web services define applications that deliver a service (usually by exposing a programmatic interface) where you can either fulfill client requests directly or integrate the provider service with other Web services using Internet standards. External consumers or applications communicate with Web services by means of XML formatted messages, usually using XML over HTTP. Both .NET-based and J2EE-based applications can implement XML Web services.

Interop Best Practices for Each Approach
Following are some of the practices that are recommended while implementing interoperability between .NET and J2EE applications.

In general, from the architecture perspective of .NET and J2EE
a. Divide a multi tiered application into three logical layer namely presentation, business and data/resource tier
b. Implement service interfaces that expose each tier's façade through the interoperability mechanisms
c. Create interoperability adapters either for each service interface or for each use case depending on the level of fine control required
d. Provide multiple abstraction layers to ensure maximum flexibility for future developments

When using Ja.NET to implement interoperability, recommended practice
a, Usage of binary protocol for .NET Remoting
Deploy WAR packages on the application server to access EJBs and JMS
b. Understand .NET Remoting to facilitate good design practice

When using Web Service to implement interoperability
Use simple data types so that it compliments each of the platform involved in interoperability
a. Base all data types on XSD data types so that this ensures that the data types is the complex data objects map to types in .NET Framework and Java
b. Separate out the data types from the proxy file and store them is a separate location. This is particularly useful when the .Net and the Java assemblies require a single XML namespace for all types

When sharing data between ADO.NET and JDBC, it is recommended
a. To abstract database access code from the rest of the application
b. For ease of coding and consistency, a layer that abstracts the database code from the business logic should be implemented

For more insights into enterprise J2EE-to-.NET interop trends, IDN spoke in depth with Marlabs' Kutarahalli.

=================================================================

An Integration Developer News interview
with Manjunatha Kutarahalli,
Marlabs Vice President-Global Delivery


IDN: Overall view on interop to IT customer to 2005? What is their pain/frustration?
Kutarahalli: I think both J2EE and .NET are establishing their play in the marketplace, so it is incumbent on those companies to make it work. But, interop Best Practices also need to come into play while those vendors work out between each other how they want to work together.

Today, for instance, we need to understand how the apps are being shared. At Marlabs, we're trying to articulate some repeatable patterns and Best Practices that would let a developer team take a certain J2EE component and put it into a .NET application, and further even separate the business logic from the app logic. That means one approach might be to stop storing your business logic in a database because that helps avoid certain rules sharing problems

IDN: How aggressive are companies getting in adopting full SOA architectures for interop? It would seem that while there is a lot of work going on at the lower levels, business and data integrations don't seem to be as prevalent?
Kutarahalli: Today, I'm not seeing what I would consider a full range SOA projects yet. Enterprise applications have 3 layers -- a business logic layer, a presentation layer, and an abstraction layer. Having applications talk to each other only at a [lower level] web services layer is really not enough - especially when you might need real-time performance, interoperability or other services, such as security or authentication.

IDN: So, do you think we have the right standards to enable SOA to be easily and effectively done?
Kutarahalli: I look at it this way. Standards have to exist, but not only at the high level or the web services level, but at all of these other layers - the data layer, logic layer and the abstraction layers.

IDN: You're suggesting we might need an "standard stack" for SOA or Java/.NET interop, much like we had one for OSI for networking a generation ago?
Kutarahalli: If you look at the OSI stack for the network, and that was a pretty good approach where they abstracted the communications. If that kind of stack existed for apps architectures using .NET and Java, people could be more comfortable in communicating at each of those layers, rather than abstracting at the highest layer.

IDN: There's no effort to create such a software architect standards stack today, is there?
Kutarahalli:: I don't think so. But, there could be. If you look at .NET and Java/J2EE today, they do the same thing today. There are the same types of abstractions. There is JDBC, there is ADO.NET. There is business layer, which could be done in Java or in C#. Both have a neutral abstraction language, and both have a common runtime environment, and for presentations layers, there is a JSP and ASP.NET.

IDN: So, what is the potential from these comparables between Java and .NET?
Kutarahalli:: Well, if developers and vendors can define "How can I call a Java API from ASP.NET," or can I call the JDBC from C#. And from that definition, create some standard interfaces that developers could just plug into from either side - wither Java or .NET. Further, developers could plug and play together different [Java or .NET] components, so a project might have business logic in Java, but have ASP.NET as a front end to consume that, just for example.

IDN: What has to happen for that to happen?
Kutarahalli: There are a number of smaller vendors that are looking at this space. There are a few Open Source projects at the language level. Borland's Janeva, Jnbridge.com and Janeva (Borland), Jacob Open Source project, Ja.net. These are at the language level. Web service song-and-dance is not enough.

IDN: Many say the standards at the lower level, are OK, but there is a need for higher level standards, for BPM, etc.?
Kutarahalli: Yes, I agree. Our customers care, but going to that level is pretty far along in their horizon. They are not going to true end-to-end web services in the next couple of years, so for them the question is how do I interoperate with these smaller pieces I have. I have some business logic sitting here and some application logic somewhere else. So, today our customers have issues that is just more simple integration, or reuse of business logic. They are really looking at full interoperability because of the lower level differences. But they are not looking at high-interop because it is too difficult and painful.

IDN: What should I do, then?
Kutarahalli: There are many options for companies, and they depend really on what they need to accomplish, and if it's a code base that is simple enough to rewrite or a complex one that want to leverage without rewriting. Today, companies are just getting teir arms around how to make a plan for interop and component-based projects to figure out if the benefit is worth the outlay in time, money and training.



back