Bridging the Gap
Soon J2EE and .Net will be running in most enterprises. Will they just
coexist in a technologic cold war? Or can they work together?
by Josh Street
December 2002 Issue
There has been a lot of talk over the past year or two about Microsoft's .Net platform and what it means for the Java computing platform. Most of the talk has revolved around the issues of market dominance and availability of the platforms in various environments. Recently, industry pundits have decided that Microsoft shops will probably upgrade to the .Net platform, but Java shops will probably continue to use Java-based technologies. This situation leads to the question: If both platforms are dedicated to providing services to network clients, won't the two platforms have to work together?
With all of the money entering the enterprise application integration (EAI) space, ignoring interoperability between these two platforms borders on negligence. This fact is driven home by the Gartner Group's prediction that by the end of 2005, 90 percent of medium and large companies will be using a mixture of Java and Microsoft technologies.
A quick note before we begin in earnest: We will consider only platform-independent solutionssave for a brief examination of some techniques making use of Java Native Interface (JNI)but plenty of platform-specific options that require varying degrees of expertise and knowledge are available. For those who want to pursue such solutions, look into creating COM wrappers for Java code and the various Java/ActiveX bridges that are available.
J2EE and .Net
Before we can seriously talk about interoperability between these two platforms, we need to understand how the two platforms are organized and how they work, and what options they provide for interacting with other platforms. The Java 2 Platform, Enterprise Edition (J2EE) is Sun Microsystems's attempt at providing a component-based framework for reusable business logic. It supports all the features normally found in the base Java programming language (including the ability to run on any computing platform supporting a Java virtual machine [JVM]), but adds transaction support, security mechanisms, a variety of persistence frameworks, an EAI framework (the new Java Connector Architecture), and enjoys wide vendor support.
In addition, J2EE specifies a road map for application development from presentation layer to server side for n-tier applications. While J2EE provides basic enterprise functionality, it has been seen as lacking in support for Web services, but these concerns have been addressed by frequent releases of the Web Services Developers Pack (WSDP).
The J2EE specification specifies Internet Inter-ORB Protocol (IIOP) as the primary communication transport for use between componentsmore specifically, Remote Method Invocation-Internet Inter-ORB Protocol (RMI-IIOP). While other transports/protocols are allowed, including Java Remote Method Protocol (JRMP) and Simple Object Access Protocol (SOAP), they are typically relegated to the role of second-class citizens.
Microsoft's .Net platform is designed to provide developers with a component-based, n-tier architecture for application development, not unlike J2EE. .Net's primary claim to fame is a unified API across multiple languages and easy-to-use features for the development of Web services. The .Net platform relies on older technologies such as COM+ to provide typical enterprise-level functionality such as transaction management, but already has facilities for security and message queues. While the platform suffers from limited availability (the platform is now available on modern versions of the Windows platform), a version for the BSD platform is expected, as well as the open source Mono project sponsored by Ximian.
Back to top