The goal of interoperability solutions is to enable point-to-point integration between components on both platforms, while preserving the object calling syntax of each platform and without introducing additional performance or management overhead. Solutions such as bridging can to some degree preserve the native object calling semantics used by the .NET and Java EE developers. Web services provide a well-supported and standards-based interface. However, interfacing using Web services changes the object calling semantics and introduces significant performance and management issues. These solutions do not address the management complexities of a mixed-system. .NET and Java EE have fundamentally different models for management and security that are not resolved by point-to-point solutions. This requires not only preserving .NET and Java EE calling semantics for component developers, but deployment of all of the components on a homogenous platform with a single management and security model. Managing interoperability solution incorporates two elements: a solution for development timerequiring multi-language support, and a solution for runtime and deploymentrequiring the hosting of multiple environments on a single platform. In the case of this reference application, it would require seamless development of the front end in the .NET environment in C# or VB.NET and deployment of both the front end and the back end on Java EE. Before delving into details of Java and .NET manageability, it is important to understand the fundamentals of the Unification strategy. Platform Unification OverviewIn the Platform Unification approach, the code and runtime environment run on one platform, for instance .NET, that is fully hosted on the interoperating system such as Java EE. This approach preserves the integrity of the .NET application and enables .NET developers to continue to develop their code, while providing deployment on a single, homogenous platform. Mainsoft's implementation of this approach in their Visual MainWin for the Java EE Platform product provides the infrastructure to use Java EE as a cross-language platformsupporting .NET languages and Java on a common Java EE platform. This allows for a unified runtime deployment environment. The Mainsoft implementation provides platform unification through cross-compilation, a Mono-based .NET environment implemented on Java EE, and integration with the development environment. Cross CompilationFor .NET code to execute in the Java EE environment, the code must be executable as compliant Java bytecode that can execute in a Java virtual machine. The Mainsoft binary compiler converts Microsoft Intermediate Language code into pure Java bytecode. The conversion must bridge the difference in .NET and Java semantics, while producing efficient and compliant code. The key elements of the conversion are Direct Mapping The compiler directly maps object structure, classes, interfaces and types, and the flow of control semantics from .NET to the equivalent Java semantics. .NET Semantics The compiler handles .NET semantics not present in Java. These semantic gaps include
Implementing this approach requires use of a cross compiler as shown in Figure 15-6. The cross compiler resolves differences in the .NET and Java platforms and produces Java bytecode output from the .NET code that is part of the application. The output of the cross compiler is Java class files that are packaged as a Java Archive File (JAR). Figure 15-6. Visual MainWin Compiler
.NET Runtime Environment on Java EE.NET code is hosted in a .NET environment running on Java EE. The Mainsoft implementation of the .NET environment is based on the open source Mono project. The Mainsoft .NET runtime environment hosts the Mono libraries by cross-compiling these libraries to Java bytecode. Mainsoft classes provide the connection between the .NET namespace provided through Mono and the underlying Java SE and Java EE runtime. The Mainsoft integration of the Mono classes includes
The structure of the runtime stack is shown in Figure 15-7. Figure 15-7. Visual MainWin technology stack
Interoperability of .NET and Java CodeInteroperability of Java code from .NET is supported natively. Because the runtime environment for all code, .NET and Java, remains the Java VM, all compliant Java code will run. The .NET programmer can access Java classes and namespaces transparently as from the .NET environment as if these classes were .NET classes. The JDK and Java EE classes are made available to the .NET developer as well. .NET classes can be called by Java code as well, provided that the .NET classes expose interfaces that can be directly mapped to Java. In a distributed environment, .NET code can reference Java components deployed either as EJBs or as Web services. Because the runtime environment is Java, point-to-point integration with EJBs is available over RMI. The .NET programmer sees the EJB as a .NET class with a .NET namespace. Additional tools in the provided development environment extensions generate wrapper code, which implements a service location pattern to map the EJB semantics of JNDI lookup and invocation of the home interface methods .NET class semantics [CORE]. .NET code can invoke Web services and implement Web service endpoints through the supported Mono implementation of the .NET System.Web.Services namespace. The Visual MainWin environment provides an API for allowing .NET programmers to access the Java EE server context. This is necessary for programmatic security and for manipulating JNDI objects such as Data Sources. Additionally conversion routines are provided to allow conversion between Java types, such as java.math.BigInteger and functionally equivalent .NET types, such as Decimal and DateTime. With this background on platform unification, the next sections elaborate on how to achieve management of .NET and Java EE applications. Interoperability Management SolutionThe Platform Unification approach enables .NET and Java EE code to interoperate by deploying all of the application components on a homogeneous Java EE environment. This achieves a cross-language/cross-environment platform with a uniform Java EE management model. Thus the challenges posed by the mixed management models described here are significantly reduced. In this model, the inter-component communications are based on native protocolseither Java method calls or RMI, and there are no additional marshaling or protocol interpretations. The platform unification model does not impose an architectural model on the components. It allows the components to be tightly or loosely coupled through .NET and Java EE Web services implementations deployed on Java EE. This architectural flexibility allows a .NET Java EE system to be designed to meet the organization structure, rather than be constrained by the interoperability technology. Additionally, the .NET semantics are preserved for the developer, but the manager has a coherent Java EE management view of the system. The management functionality leverages the Java EE platform and is not limited to the cross-platform implementation of Mono. Platform Unification ISO Management CharacteristicsThere are significant benefits in meeting the management requirements just defined.
This model allows the .NET components to benefit from the Java EE security model, allowing the use of Java EE declarative security. The access to the Java EE APIs also allows the use of programmatic security. Benefits and LimitationsThe Platform Unification approach, by design, assumes that the target deployment platform for both the Java EE and .NET components is Java EE. This strategy does not explicitly facilitate management of Java and .NET applications deployed on the Java EE platform. There is no added management functionality such as service lifecycle monitoring or metering provided with this solution. The Java EE application server typically provides management facilities that can be used along with commonly deployed enterprise management solutions such as CA Unicenter. The Platform Unification approach is not appropriate where Microsoft-specific applications, such as Exchange or BizTalk-based applications, are necessary. Integrations with other applications that require native Windows functionality are also not suitable for this approach. The integrated development process requires access to the .NET source, in order to support the develop/compile/cross-compile/debug cycle. Thus this approach would not be applicable where the .NET source is not available to be recompiled. The Co-Development ExperienceThe diversity of expertise of developers in a mixed platform development contributes to the productivity of the IT organization. However, the divergence of the development environment, such as the .NET and Java EE environments, presents a challenge for organizations with both .NET and Java EE development teams. The Visual MainWin tool set for platform unification provides the .NET development team with full integration for the Visual Studio .NET development environment. This preserves the development experience for each team and allows the .NET developer to continue to develop .NET code while deploying components on Java EE. The developer builds a .NET project configured for Java EE servers and the complete build process from C# or VB.NET compilation through binary compilation to Java bytecode validation of Java references, as well as the packaging as Java EE JAR and WAR files, is performed within Visual Studio. Application deployment on Java EE servers is managed, again, from within Visual Studio .NET. The Visual MainWin integrated debugger enables C# or VB.NET programmers to debug applications running in the Java EE application server at the .NET source code level. The Visual MainWin environment simplifies the integration of Java and EJB components into the .NET code, as just described. This model allows the .NET team on-going integrated development with the Java EE team. |