Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / UML

.NET and J2EE interoperability for .Net Developers

4.54/5 (10 votes)
31 Dec 2007CPOL7 min read 3  
.NET and J2EE interoperability for .Net Developers

Introduction

In this paper we will compare J2EE and .Net technologies. We will explore the Interoperability scenarios and available options. Also, this paper is written for .Net developers, who are at advanced level of .Net knowledge and having no or minimum knowledge of J2EE.

Interoperability Overview

"Interoperability: The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units."
—ISO/IEC 2382 Information Technology Vocabulary

Many Enterprises have been building based on mixed environments i.e. J2EE and/or .Net. If company sees a need of new application to their current enterprise, first thinking is to reuse and/or integrate the new application with existing applications and systems. Integrating systems with partners and suppliers is another increasing demand by businesses/enterprises, where security, performance and scalability come as standard requirements.

Migrating, rebuilding or replicating the functionality is not possible in most of cases. Even if we decide to migrate application(s) to other platform, most of the time migration has to be phased and integrated with other platform until complete system migration.

Interoperability allows the core systems to communicate with internal and external applications including partners and suppliers. Performance overhead, security and reduction in functionalities should be considered while designing solutions for interoperability.

In coming sections we will explore following topics:

  1. Interoperability Scenarios and technology mapping
  2. Interoperability Technologies
  3. J2EE for .Net Developers
  4. .Net and J2EE Feature Mapping
  5. Interoperability using XML
  6. Summary

Interoperability Scenarios and technology mapping

Following are the common Interoperability scenarios in an Enterprise:

  1. .Net Presentation Layer with J2EE Business Layer
  2. J2EE Presentation Layer with .Net Business Layer
  3. .Net Business Layer with J2EE Business Layer
  4. Sharing resources between .Net and J2EE

Note: Above are most common scenarios but not all, for instance there is also a possibility of .Net Presentation and J2EE Presentation layer interoperability.Please See “Interoperability Technologies” section for mapping between scenarios and technologies recommendation.

Following diagrams maps the layers and shows above interoperability scenarios:

Image 1
.Net Presentation Layer with J2EE Business Layer




Image 2
J2EE Presentation Layer with .Net Business Layer

Interoperability Technologies

There are multiple technologies for .Net and J2EE interoperability. Each technology has pros and cons. It also depends on your functional and/or non-functional requirements i.e. performance or scalability. Following are the technologies, which we can use for interoperability between J2EE and .Net:

  • XML Web Services
  • Runtime Bridges
  • Message Orientated Middleware
  • Shared Database
  • Integration Brokers

*Please note following is a high level overview of each technology from interoperability point of view. For more information please use appropriate resources.

XML web services have been matured by the time and are supported by both J2EE and .Net. Web services provide an interface for communicating with other applications and systems. However, web services hide the method level implementation, therefore applications can only communicate through defined interfaces and contracts. Web service is a good choice for Presentation to Business, Business to Business and Business to Data interoperability.

Using XML web services, you cannot call a class method or access J2EE classes from .Net or vice-versa. Runtime Bridges provides the ability to access classes from one platform to another. Runtime Bridges are developed by 3rd parties, JNBridgePro and Ja.Net are most prominent in the market. Runtime Bridges allows you to use .Net Remoting to handle classes at Java side.

Messaging and Share databases provide asynchronous communication mechanism. Messaging is based on MSMQ and IBM MQSeries and both supports security, message recording and transactions. Using the share database technique, one common database (SQL Server or Oracle etc.) is being accessed by .Net and J2EE applications. .Net application uses ODBC and J2EE application uses JDBC.

Integration Brokers are typically built on messaging framework that provides the integration and automation between business processes across distributed applications and Enterprise. Integration brokers are a good answer for integration of partners and suppliers. BizTalk Server, CommerceBroker and IBM MQSeries are the most well-known integration brokers in the market.

Following table shows the mapping between interpretability scenarios and technologies. These recommendations are from Microsoft and could differ to your problem and solution.

Web Services

Runtime Bridges

Messaging

Share Databases

Integration Brokers

Presentation to Presentation

X

X

Presentation to Business

X

X

X

Business to Business

X

X

X

X

Business to Data

X

X

X

J2EE Overview for .Net Developers

Unlike Microsoft .NET, Java 2 Platform, Enterprise Edition or J2EE is a set of linked specification but not a product. These specifications consist of a series of downloadable .PDF files that describe application agreements and the makeup of the containers in which these applications run.

Sun Microsystems developed Java as platform and a programming language.
There are currently three editions of the Java platform:

  • J2SE (Java 2 Standard Edition)
  • J2EE (Java 2 Enterprise Edition)
  • J2ME (Java 2 Micro Edition)

Note: The term “Java” mostly refers to functionality available within J2SE. Areas that require the Enterprise Edition include the term J2EE.

For more information about J2EE history please visit http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#History

As mentioned before J2EE is a series of specification but platform unlike .Net. There are other differences between J2EE and .Net, which should also be understood. Differences can be categorized in three main areas:

  1. Operating System
  2. Language Support
  3. Execution Process or Technique

As we know, .Net can run only on Windows platform but Java was designed to run on multiple platforms i.e. Windows, UNIX, Linux, MacOS and BeOS.

We can write applications in Java using Java Programming Language only but in .Net you can write applications in any language, which is supported by .Net.

There is also a major difference between the two platforms at application run time. When you build a project based on a .NET language, the output consists of MSIL code that the JIT compiler compiles at runtime. To deploy a Java program, you compile the application to create Java bytecode. The JVM running on the target operating system then interprets this bytecode to produce the relevant instructions.

Note: There are also Java JIT compilers that work in a similar fashion to the .NET Framework component.

Some of the vendors have created their own implementations of J2EE specification, which were built by Sun Microsystems. Following vendors implemented these specifications:

  • Sun (Sun ONE Application Server)
  • IBM (WebSphere)
  • BEA (WebLogic)
  • JBoss (Open source implementation) http://www.jboss.org/

J2EE also includes additional components, which were evolved over the past decade:

  • Java Server Pages (JSPs)
  • Server side APIs or servlets
  • Enterprise Java Beans (EJBs)
  • Java Naming and Directory Interface (JNDI)
  • Java Message Service (JMS)
  • Java API for XML-based RPC (JAX-RPC)
  • J2EE Connector Architecture
  • J2EE Management Model
  • J2EE Deployment API
  • Java Management Extensions (JMX)
  • J2EE Authorization Contract for Containers
  • Java API for XML Registries (JAXR)
  • Java Transaction API (JTA)
  • Common Object Request Broker Architecture (CORBA)
  • JDBC data access API

You can map few components in .Net e.g.,JMS is equivalent to System.Messaging namespace.

.Net and J2EE Feature Mapping

Following table helps to understand the comparison of J2EE and .Net features.

Feature

J2EE

.NET

Type of technology

Standard

Product

Middleware Vendors

30+

Microsoft

Interpreter

JRE

CLR

Dynamic Web Pages

JSP

ASP.NET

Middle-Tier/Server Side Components

EJB

.NET Managed Components

Database access

JDBC SQL/J

ADO.NET

SOAP, WSDL, UDDI

Yes

Yes

Implicit middleware
(load-balancing, etc)

Yes

Yes

Web Apps Hosting

Multiple (depends on vendor implementation)

Internet Information Server

Directory Access

Java Naming and Directory Service (JNDI) through LDAP

Active Directory Services Interface (ADSI) through LDAP

Remote Invocation

RMI-IIOP

.NET Remoting

Messaging

JMS

Microsoft Message Queuing

Transactional Support

JTA

COM+/Distributed Transaction Controller (DTC)

Summary

It is not possible or appropriate for Enterprises to build systems based on only J2EE or .Net technologies. Some organizations have already built their core systems using J2EE or .Net platform and interoperability is an ongoing requirement for enterprises. There are different types of Interoperability i.e. Presentation to Business or Business to Business layers and there are multiple recommended technologies to these interoperability types. In past decade SOA and Enterprise Service Bus have become prominent and mature in Enterprises .These techniques will provide more scalable and extendable architectures, which makes interoperability much easy and seamless.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)