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, including Web services, bridging solutions, the Enterprise Service Bus, and cross-platform solutions such as Mono, and each one impacts manageability differently. Recently, a new strategy has emerged: Platform Unification, the aim of which is to attack interoperability problems at their root. Platform Unification delivers a unified runtime application stack that removes the need for complex interoperability solutions.
Why Do We Have Mixed-Mode Systems
Complex mixed-mode data centers arise for a variety of reasons. Rarely are they brought about deliberately by design. Generally they evolve into their state of complexity over time with the constant addition of new products meeting new technical, product and business requirements. Some common scenarios are:- Mergers and Acquisitions: Generally, 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, the relevant IT organizations are handed the task of getting hugely different technology bases to somehow integrate to form a coherent whole. It is not uncommon for a company that uses J2EE end-to-end to find itself acquiring or being acquired by one that uses .NET in a similar manner. But now they have to make their systems work together.
- Changes in Management or Strategy: 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 to move new product development to the Microsoft platform; or conversely, companies concerned about the frequency of security holes found in IIS may prefer to move to J2EE. After this decision, their new product development will have to still interoperate with their old products built on the ‘other’ technology.
- Successful Department-Level Applications: 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.
- Desire for Service-Orientation: 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.
- High Development Costs: Cutting costs is always a major business driver. As new, cheaper technology bases arrive on the scene, companies will jump aboard to take advantage of 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 making a decision on which route to take, companies need to consider Fault Management, Configuration Management, Accounting Management, Performance Management and Security Management.Web Services
Web services have 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 the 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. It is limited because Web services, being stateless in nature, and not message-driven, cannot 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 the 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, Web services 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 Web services distributed management (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 to 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 is still a long way to go.
Bridging Solutions
Bridging solutions are tightly coupled solutions that provide 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 handles 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.These include:
- Fault Management: Bridging solutions do not 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.
- Configuration Management: Commercial solutions for the above scenario include Borland Janeva and JNBridge. These require runtime configuration by means of text files containing the relevant information. These files need 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.
- Accounting Management: Generally bridging solutions do not integrate with the underlying management APIs, and do not offer the facility for unified accounting.
- Performance Management: Bridging solutions bring an overhead to the performance of the system which is significant, and in some cases can be major. The runtime data marshalling can reduce overall performance.
- Security Management: Security and security context management handling can vary from implementation to implementation, but when using a bridging solution, a new channel of communication is introduced which may or may not allow for a compatible security context with the rest of your J2EE or .NET architecture.
EAI Applications
There are many EAI applications designed for application integration. Examples are WebSphere Business Integration, Microsoft BizTalk, TIBCO and BEA products. These provide an architecture and a runtime environment that uses adapters to provide a translation layer between different standards to a single internal data format, which 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 forth 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 similarly to the bridging methodology.The Enterprise Service Bus
The Enterprise Service Bus 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 applications (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, but with one major and important difference – with the Enterprise Service Bus, the ‘hub’ on which all traffic flows is open and standards-based and not proprietary. Therefore, connectors for different technology types may be chopped and changed between different ESB implementations. Also, when it comes to management, standard management platforms would be able to be used, as opposed to ones that are 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 it is an amalgamation of all forms of application integration, using adapters to set a common means of communication, it should fare similarly to 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 these 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’s being used successfully 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 the key management elements such as Fault Management, Configuration Management, Accounting Management, and Performance Management would therefore need 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. Therefore, interoperability between Mono and a WebSphere-based application can still be implemented and managed using technologies built on Mono such as Web services.Platform Unification
The management of mixed-mode systems brings enough challenges of its own without adding more through an interoperation technology such as Web services or bridging. This is part of the rationale behind the Platform Unification strategy designed and implemented by Mainsoft through its Visual MainWin for J2EE.This product establishes compile-time conversion of C# or VB.NET code to Java bytecode that runs on a J2EE application server. As such, .NET applications will interoperate with ones running on J2EE as they will be running within the same JVM, and cross process communications through bridging, Web services and the like is not necessary. Thanks to the open source nature of Mono, Mainsoft used their technology to rehost the .NET Framework on J2EE. Using Visual Studio .NET, through the Visual MainWin for J2EE plug-in, developers can code, compile, deploy and debug their .NET applications on J2EE. Additionally, .NET applications, as they are implemented as Java bytecode can be integrated directly into Java applications, and Java assets such as EJBs can be consumed from ASP.NET applications without going through a bridging technology.
After a merger, a Fortune 100 insurance provider realized that its two technology bases were wildly different and must be made to work together. The IT team now consisted of IBM expertise and more than 1,000 Visual Studio developers who had been supporting a homegrown Windows portal. The company’s technology challenge included aggregating enterprise applications on disparate platforms for end users and partners. Mainsoft demonstrated the ability to deploy the customer’s ASP/VB6 applications on WebSphere Portal in less than 5 staff days, and the company selected WebSphere Portal as a best-of-breed solution.
From a management point of view, the Platform Unification strategy is a strong approach.
- Fault Management: Monitoring, event handling, logging, etc. are all implemented using the underlying J2EE mechanisms, and are fully compatible with the J2EE environment and any existing management systems, such as Tivoli.
- Configuration Management: Overall systems management is greatly simplified due to the homogenous nature of the platform. Tuning, updates and patch management are performed for a single system configuration as all components are deployed as J2EE modules. Application management and update deployment are also greatly simplified. All resources can be managed uniformly through the J2EE management console.
- Accounting Management: As the underlying technology system is now standardized on the J2EE one, integrating with accounting management for SLA and other metrics is straightforward.
- Performance Management: It has been found that re-hosted ASP.NET applications have roughly equivalent performance to natively hosted ones. However, performance in mixed-most systems can actually increase as translation technologies such as bridging, EAI or Web services aren’t necessary when using Platform Unification
- Security Management: Under the Platform Unification model, security is provided through J2EE. This homogenous model is used across the application, and allows for management of users, authorization and authentication within a single domain. This simplifies the management of security, and eliminates the need to synchronize user and authorization stores across multiple domains. It also decreases security risks of credential information being passed between domains and platforms on wire protocols such as HTTP or HTTPs. Finally, it allows .NET components to benefit from the J2EE security model, allowing the use of J2EE declarative security. .NET code can access J2EE APIs and this allows the implementation of programmatic security.
Conclusion
Mixed-mode systems are common, and attempting to manage data centers in which they are present is a challenging task. When applications need to interoperate with each other, and those applications run on diverse platforms, the management is made more complex by the technology layers that are necessary to get systems to talk to each other. In this article you read about some of these technologies, and evaluated them from the points of view of Fault Management, Configuration Management, Accounting Management, Performance Management and Security. Each major technology: Web services, bridging, EAI and the Enterprise Service Bus was introduced and evaluated from the point of view of each of these manageability characteristics. Additionally, the concept of Platform Unification, whereby .NET Framework-based applications may be rehosted on J2EE, reducing the need for interoperability layers and reducing overall complexity, was introduced.Laurence Moroney is a Senior Architect for Mainsoft, and a specialist in Enterprise Architecture and Web Services Interoperability. He wrote Expert Web Services Security in the .NET Platform, ASP.NET 1.1 with VB.NET and Pro ASP.NET 2.0 in VB.NET. Laurence is also co-author of .NET/J2EE Interoperability: Integration Strategies, Patterns and Best Practices, which will be published by Prentice Hall in 2006.
Comments