Impact of Interoperability on Management

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 Remoting

Bringing 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 Characteristics

Bridging solutions such as those described do not address key management elements, although they enable point-to-point interoperability.

• Fault Management Bridging solutions do not offer resolution or integration of the underlying management APIs, and so they do not offer integration with .NET or JMX -based metering or event logging.

• Configuration Management Commercial bridging solutions based on .NET Remoting such as Ja.NET or JNBridge require runtime configuration through specific configuration files. Components need to be deployed both on the .NET and on the Java EE sides of the application, and stub/proxy pairs may need to be regenerated when deploying version updates.

• Accounting Management Bridging solutions do not offer resolution or integration of the underlying management APIs and so do not offer a unified accounting framework.

• Performance Management Bridging solutions introduce an additional component and communication channel into the system. The runtime marshaling and unmarshaling and object mapping, along with the proxy code, introduce overhead and can reduce end-to-end performance, particularly in fine-grained access and call by value scenarios. As stated previously, because there is no resolution of the management APIs, there is no coherent metering framework.

• Security Management The propagation of the security context does not provide the functionality of the .NET channel nor of Java EE RMI. These runtime components may offer clustering, failover, and enterprise level resource management that are provided by enterprise class application servers, see [MSDL1], [INTRDL1], and [JNB].

The next sections explore management semantics of CORBA-based integration strategy.

CORBA

CORBA-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.

Mono

Mono 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 Limitations

Walking through common integration strategies allows side-by-side comparison. Table 15-1 outlines advantages and shortcomings of individual integration technologies.

Table 15-1. Benefits and Limitations of Integration Technologies

Interoperability Technology	Implementations	Benefits	Limitations
Web services	Standards based implementations for .NET (Microsoft) and for Java EE (Java EE 1.4)	Web services enable loosely coupled applications to interoperate using standards (WS-I). They are firewall friendly, and it's easy to extend the protocol using SOAP. Web services also enjoy broad developer and infrastructure support.	Web services add the overhead of SOAP XML processing to each method invocation, as well as the overhead of the underlying HTTP transport. Web services security implementation and other Web services standards are not yet uniform across platforms, [WAGNER].
Bridging	Commercial products such as Ja.NET, JNBridge	Bridging solutions provide a more tightly coupled application interoperability solution than Web services. They offer the performance advantages of binary streams when compared to Web services. In addition, bridging solutions offer simplicity for the .NET programmer and preserve the .NET remoting syntax. This technology can offer pass-by reference, which means the developer works with the actual object, rather than an object copy.	Bridging solutions add overhead for marshaling protocol translation, and the bridging run time engine may introduce scalability limitations. Bridging solutions do not uniformly support distributed security models or distributed transactions.
CORBA RMI/IIOP channel	Commercial products such as Janeva Several open source implementations	CORBA RMI/IIOP channel offers the performance advantages of binary streams. In addition, this technology is transparent to the Java EE application. These solutions support context propagation for security and transactions over IIOP.	CORBARMI channels add overhead for the protocol translation, and may introduce scalability limitations. The solution can require use of a proprietary API by the .NET programmer and extensive configuration.
		The developer typically applies this model to a .NET front-end Java EE back-end architecture.
Mono	Open source frame work, adopted by Novell	Mono enables .NET applications to execute on other platforms, such as Linux. Mono supports a wide set of the .NET namespaces, such as ASP.NET and ADO.NET.	Mono does not yet support enterprise services. Mono does not integrate development into the standard .NET development tools.

The next section takes a look at best practices and limitations pertaining to the Java EE .NET management task.