Enterprise

Due to the benefits of each, J2EE and .NET have penetrated most markets and companies to the point where 95% of medium and large-scale enterprises support both .NET and J2EE, and 30% or more of new application development will include both by 2009, according to a study published by Gartner. Data centers of these companies rarely work in "silo" mode where J2EE and .NET work independently and don't need to interoperate with each other, but instead form a mesh of applications in what is termed a "mixed-mode" deployment. These deployments have driven the emergence of standards such as Web Services to ease their integration.

To ensure that applications can run across such diverse platforms and have acceptable availability, performance, scalability. and security characteristics is quite a challenge. Several technologies are typically used to enable interoperability between .NET- and J2EE-based systems. However, each solution introduces manageability issues. Platform unification, on the other hand, attacks interoperability problems at their root by removing the need for complex interoperability through a unified runtime application stack.

Why Do We Have Mixed-Mode Systems?
Complex mixed-mode data centers arise for a variety of reasons. They are rarely deliberately mixed-mode by design. Instead, they become complex over time with the constant addition of new products meeting new technical, product, and business requirements. For example, when a company is considering a merger or an acquisition, the primary driver is business alignment. Typically the underlying technology used to run the data centers and the products of each business party is not a major factor, and only after the business transaction is complete are the relevant IT organizations handed the task of making hugely different technology bases somehow integrate to form a coherent whole. It's not uncommon for a company that uses J2EE end-to-end to find itself acquiring or acquired by one that uses .NET through and through, and now they have to make their systems work together.

Sometimes changes in management or strategy are the reason a company ends up with a mixed-mode system. As technology evolves, a company that is vested in a particular strategy may have many reasons for wanting to change it. For example, companies that don't like the complexity of J2EE development may be seduced by the relative simplicity of .NET and move new product development to the Microsoft platform. Conversely, companies concerned about the security holes found in IIS may prefer to move to J2EE. After this decision, their new product development will still have to interoperate with the old products built on the "other" technology.

Also, companies that use one technology coherently on the strategic corporate level, but allow other technologies on the department level can experience great success with some department-level applications. Should they want to extend these to the rest of the enterprise, they will require an interoperability or migration strategy.

Others are service-driven when implementing different platforms. Many companies want to simplify their intra-company interoperability, or their interface to their customers by providing Web Services. Integrating with other business partners or customers who use different technology bases will require a cross-technology interoperability solution.

And naturally, cutting costs is always a major business driver. As new technology bases arrive on the scene, and can cut development costs relative to older ones, companies will jump aboard to take advantage of the cost savings. However, in many cases new products will still have to interoperate with older ones built on different platforms.

Interoperability Strategies and Solutions
The interoperability problem is a common one, and as such there are many solutions available from software vendors to ease and solve them. When considering a cross-platform solution, one must consider fault management, configuration management, accounting management, performance management and security management.

Web Services
Web Services has emerged as the ipso facto standard in connecting disparate systems due to their abstract nature: they use XML throughout from description to discovery, and their underlying technical implementation is entirely abstracted as a result. Hence they would appear to be the ideal solution for interoperability. If your application can be implemented on a platform that supports Web Services, or at least "wrapped" in one, then this provides an excellent, though limited solution. Limited because Web Services, being stateless by nature, and not message-driven can't be used in all circumstances. Additionally, technology implementations by different vendors lead to commonly reported interoperability problems when moving across the J2EE/.NET divide.

From a management point-of-view, the following observations are made with regard to Web Services:

• Fault Management: Web Services are widely adopted and are associated with many standards so that if the Web Service is implemented using a standard, then it can be trusted to meet the appropriate criteria. In the case of management and fault management, WS-Management and Management of Web Services (MOWS) standards encapsulate this. If the service is written to these standards, then many tools that allow for fault management and analysis are available.
• Configuration Management: Standards such as WSDM and MOWS address the issues of configuration management such as service changes, deployment, and lifecycle management.
• Accounting Management: MOWS addresses the functionality of metering services as well as auditing and integration with modules such as Service Level Agreement (SLA) management.
• Performance Management: Here is where Web Services break down from a management point-of-view. They introduce significant overhead in their need to process intricate XML documents for SOAP and WSDL. When the service adheres to specifications such as WS-Security and WS-Management the complexity of these documents, and thus the performance hit can increase exponentially.
• Security Management: There are many emerging standards that help Web Services be secure: WS-Management defines a schema format that allows message content to be encrypted and signed for security, non-repudiation, and identity. Web Services security still has to face the challenge of single sign-on where processes that run across diverse platforms have to authenticate themselves on each platform effectively. Great strides are being made in this area, but there's still a long way to go.

Bridging Solutions
Bridging solutions are tightly coupled solutions providing a messaging transport and translation layer between components running on diverse systems. Reviewing a hypothetical example system where the front-end presentation tiers are developed using ASP.NET and the back-end business logic and data management tiers are implemented on J2EE, a typical bridging solution would provide a layer that the ASP.NET could call using remoting or other familiar semantics. The bridging solution would handle the low-level details of the communication allowing developers to call remote objects passing data, state, and the like. This may appear at first to be an elegant strategy, but it does suffer from challenges insofar as management is concerned.

Consider fault management. bridging solutions don't integrate tightly with the underlying management APIs of either J2EE or .NET. Standard or integrated metering and logging of either of these may not be effectively leveraged.

Where configuration management is concerned, commercial solutions for the above scenario include Js.NET and JNBridge. These require runtime configuration by means of text files containing the relevant information. These files have to be carefully deployed and managed on both sides of the system, and in many cases may need to be regenerated upon small changes to the system.

Generally bridging solutions don't integrate with the underlying management APIs, and don't offer a facility for unified accounting.

And, performance is sometimes compromised. Bridging solutions bring an overhead to the performance of the system that is significant, and in some cases major. The runtime data marshalling can reduce overall performance.

Plus, security issues arise because security context management handling can vary from implementation to implementation, but when using a bridging solution, a new channel of communication is introduced that may or may not allow for a compatible security context with the rest of your J2EE or .NET architecture.

EAI Applications
There are many Enterprise Application Integration applications designed for application integration such as WebSphere Business Integration, Microsoft BizTalk, TIBCO, and BEA products. These provide an architecture and runtime environment that uses adapters to provide a translation layer between different standards to a single internal data format that is then managed by the EAI application and dispersed where appropriate. It can be viewed as a "super-bridging"- type solution where the bridge doesn't connect system to system, but instead a series of bridges connect different systems to a single hub having its own messaging and communication format. These bridges also connect the hub back to the different systems so that translated messages can be passed to and fro between them, using the centralized hub as the transport mechanism. As such, it can be seen that from the point-of-view of management, it should fare about the same as the bridging methodology.

The Enterprise Service Bus
The Enterprise Service Bus (ESB)is an evolving concept, having grown from the concept of Web Services, but stretching beyond the simple request/response model offered by Web Services into the entire realm of application integration. The concept is modeled around a common communications pathway, a bus, to which all types of application (request/response, asynchronous, message-driven, legacy, etc.) are connected via adapters. Thus all information flows on a common information bus, using a common format: SOAP. Architecturally, from a high level it appears to be very similar to EAI-style applications, and it is -with one major and important difference. With an Enterprise Service Bus the 'hub' on which all traffic flows is open, and standards-based, not proprietary. Therefore, connectors for different technology types can be chopped and changed between different ESB implementations. Also, when it comes to management, standard management platforms would be usable, as opposed to ones designed for the proprietary format of EAI applications.

The concept is interesting, and in its infancy, so ascertaining its manageability is difficult. However, one can deduce that as an amalgamation of all forms of application integration, using adapters to set a common means of communication, it should fare like the bridging methodology when it comes to gauging its manageability. Once new management platforms appear that can interface with the standard formats used by the ESB, its manageability characteristics should improve drastically. The closeness of ESB to Web Services from a data point-of-view should mean that they will evolve rapidly.

Mono: A Cross-Platform Implementation of .NET
Mono is an Open Source project, sponsored by Novell, that aims to bring the power of the .NET Framework and the flexibility of development in C# and VB.NET to platforms other than Windows. It encapsulates an implementation of the CLI runtime as well as implementations of many of the .NET Framework APIs and system classes. It has been successfully used in migrating large applications from Windows to Linux - for example, a recent project by the city of Munich used Mono to migrate their ASP.NET applications to a large-scale deployment of over 300 Linux servers. Mono implements a subset of the .NET management APIs, but doesn't provide an integrated management framework across platforms, nor does it integrate them with native management functionality that may be present on the operating system. The implementation of key management elements such as Fault Management, Configuration Management, Accounting Management, and Performance Management would therefore have to be implemented by the application developer. It's important to note that this isn't necessarily a limitation of Mono, since Mono isn't intended to be an interoperability solution, but a multi-platform one. It is, however, open, extensible, and continually adding new features, so with a little effort it can be a very effective solution. So interoperability between Mono and a WebSphere-based application can still be implemented and managed using technologies built on Mono such as Web Services.