There are many ways by which companies can integrate Java EE and .NET applications. Some of them use technologies discussed in the book such as Java implementation of .NET Remoting and Web services. Additionally, there are strategies like CORBA discussed later in this chapter. There are cross-platform strategies that involve deployment of the application on a different platform. A .NET application can be deployed on a Unix platform using the Mono open source project, which provides an implementation of the .NET Framework for development and deployment of applications on a Unix-based environment. See [Mono]. Each of the solutions impacts the management infrastructure differently. It is important to note that these solutions do not solve underlying differences in platform security and management architecture. Bridging/.NET RemotingBringing solutions allow tightly coupled point-to-point connectivity between .NET and Java EE components, while largely preserving the native calling semantics of each system. These solutions provide a runtime component to handle the wire protocol and marshaling and use tools to generate proxy classes that hide the details of the communications. This allows developers to call remote objects on other platforms with functionality that includes pass-by reference, object statefulness, and singleton objects. In the case of this reference system, a bridging solution enables the front-end components to access the back-end warehouse components with the semantics of .NET Remoting. The bridging solution would introduce a runtime component that would translate .NET Remoting semantics to a wire protocol, such as CORBA and IIOP or a proprietary protocol over TCP or HTTP/SOAP. The runtime component would then invoke the Java EE components on the back end. The .NET developer would access the back-end EJB classes using .NET proxy classes that would be generated using the development tools. Bridging/.NET Remoting and ISO Management CharacteristicsBridging solutions such as those described do not address key management elements, although they enable point-to-point interoperability.
The next sections explore management semantics of CORBA-based integration strategy. CORBACORBA-based bridging solutions, such as Borland's Janeva, provide .NET Remoting semantics for CORBA-IIOP-based communications. By relying on the wide support for RMIIIOP across Java EE application servers, these solutions provide a standards-based bridge [JRMI]. This functionality includes propagation of security, transaction, and QOS context to back-end Java EE servers [OMG]. The solution includes a runtime component that translates .NET Remoting to IIOP at the wire level and handles marshaling and type mapping. Development tools are provided to generate the necessary stubs. To leverage the propagation of the calling context, the .NET programmer needs to use a proprietary API. There is no automatic mapping of the .NET channel context to the CORBA calling context. Janeva supports load balancing and failover through its QOS facility and interceptors [BORJAN]. From the viewpoint of the key management elements, CORBA-based bridging solutions can leverage context propagation for security and transaction management. This allows for the propagation of user credentials, such as for ASP.NET front-end authentication to propagate security identities to Java EE servers. However, the underlying problem of the different .NET and Java EE security models is not addressed. Performance management in the CORBA-based solution is impacted by the CORBA runtime, as well as marshaling of data types and .NET type mapping, which introduces significant overhead. Configuration management has the additional complexity of the CORBA configuration. MonoMono provides .NET developers targeting Linux or other Unix environments with an implementation of the standard CLI runtime, a C# compiler, and implementations of the .NET APIs including System classes, ASP.NET classes, and ADO.NET classes. Mono can be used to deploy a .NET application on Linux, Solaris, or MacOS X. A recent project by the city of Munich used Mono to migrate their ASP.NET and Web services applications to a deployment on 300 Linux servers [MCMILL]. From a management viewpoint, Mono provides management functionality through the implementation of the .NET APIs. Mono does not provide an integrated management framework across platforms or integrate the management APIs with the native management functionality, such as that provided by the underlying Unix or Linux platform. Mono provides partial implementations of the System.Diagnostics namespace. It does not currently provide support for instrumentation or WMI in the Mono runtime. The implementation of key management elements under Mono such as fault management, configuration management, accounting management, and performance management is incomplete with respect to the full .NET functionality. Mono provides an implementation of the ASP.NET security framework. This implementation is not integrated with security functionality in the system, such as user management. Benefits and LimitationsWalking through common integration strategies allows side-by-side comparison. Table 15-1 outlines advantages and shortcomings of individual integration technologies.
The next section takes a look at best practices and limitations pertaining to the Java EE .NET management task. |