Application Management

Digg This!

Page 2 of 3   « previous page   next page »

These include:

• 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.
• Configuration Management: 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 deployed carefully and managed on both sides of the system, and in many cases may have to be regenerated on small changes to the system.
• Accounting Management: Generally bridging solutions don't integrate with the underlying management APIs, and don't offer the facility for unified accounting.
• Performance Management: 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.
• 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 tht may or may not allow for a compatible security context with the rest of your J2EE or .NET architecture.

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.

The concept is interesting, and in its infancy, so ascertaining its manageability is difficult. However - one can deduce that since it's 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.

EAI Applications
There are many EAI applications designed for application integration. Examples are WebSphere Business Integration, Microsoft BizTalk, TIBCO, and BEA products. These follow similar principles to the Enterprise Service Bus, whereby adapters 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 appears to be very similar to the Enterprise Service Bus, and it is, but for one major difference - in EAI applications the communication and data representation format is generally a proprietary format, whereas with the ESB it's standards-based. From the point of view of management, it should fare like the Bridging methodology.

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

Visual MainWin for J2EE establishes compile time conversion from .NET Framework-based code such as C# or VB.NET to Java bytecode that will run on WebSphere. As such, .NET applications will interoperate with WebSphere applications by running directly on WebSphere. Given the Open Source nature of Mono, Mainsoft can convert the supported .NET Framework classes to Java, providing a .NET Framework runtime that runs on WebSphere. In a symbiotic fashion, Mainsoft then returns significant amounts of code and QA to the Open Source community. In addition, Visual MainWin is implemented as an add-in to the Visual Studio.NET IDE, enabling developers to use a familiar coding environment. Developing, deploying, and debugging applications on J2EE is seamless and virtually identical to their experiences on the Windows/IIS platform. (see Figure 1)

This solution removes the need for additional interoperability technologies are such as Web Services, or Bridging, although the former is certainly an excellent technology for presenting a consumable API frontend to customers should it be required.

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 WebSphere 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 since 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.
• Security Management: Under the platform unification model, security is provided through J2EE. This homogenous model is used across the application, and allows managing users, authorization, and authentication in 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 lets .NET components 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.

Page 2 of 3   « previous page   next page »