Application Management

Mixed-mode deployments where the data center has a mixture of different technology platforms, hardware, and software and where those platforms interoperate together to deliver software applications is the norm rather than an exception.

Experience shows that it's a challenge getting applications to run across a diverse array of software and hardware platforms with acceptable availability, performance, scalability, and security. As such, several methodologies and standards of integration or interoperability have evolved, the most common being Web Services, which despite their power and flexibility, aren't magic bullets to easy integration, and should be used only where appropriate.

This article will review several strategies for designing mixed-mode deployments and how they impact manageability. A low-level interoperability strategy from Mainsoft, called Platform Unification, will also be introduced to solve many of the problems of interoperability technologies, without adding layers of complexity for development, assurance, deployment, and management.

I'll share best practices on how to design applications to make the most of existing assets, and minimize the difficulties brought about by technology diversity. In particular, I'll focus on the interoperability needs of an application that runs partially on the Microsoft .NET framework using the Windows operating system and Intel-based hardware, and partially on WebSphere running on any operating system and IBM's z9, zSeries, or other eServer platforms.

Emergence of Mixed-Mode Systems
Mixed-mode systems exist for myriad reasons, including:

• Mergers and Acquisitions: Corporate executives considering a merger or acquisition focus first on aligning their businesses. It's therefore not uncommon for a company that uses WebSphere to suddenly find it needs a system that's open to .NET.
• High License Costs: With the advent of Linux as a 'low-cost' or 'no-cost' operating system, a company heavily invested in .NET may try to reduce costs by deploying new assets to Linux, which will then need to interoperate with existing systems.
• Successful Departmental-Level Applications: Companies that use J2EE at the strategic corporate level, but allow other technologies at the department level, may require interoperability at certain function points. Management may also want to implement company-wide department-level applications that require interoperability or migration to a J2EE architecture.
• Desire for Service Orientation: Many companies want to simplify their interoperability to become service-oriented either within the enterprise and/or to external customers. Integration directly with business partners or customers often necessitates a cross-technology interoperability solution.
• High Development Costs: The business driver of cutting costs may also impact development costs. Many companies have diverse pools of talent across technology realms, but need them focused on a specific task, thereby cutting training, licensing costs, etc., and possibly reducing "wasted" manpower.

Strategies for Interoperability
There are several strategies that allow for interoperability between.NET- and WebSphere-based software platforms. These include Web Services, bridging solutions, cross-platform implementations of .NET, and an innovative Platform Unification approach from Mainsoft where ASP.NET code runs on WebSphere, using the J2EE runtime, and allowing for much lower-level interoperability than achieved with other solutions. Platform Unification allows for .NETFramework-based applications to make the most of IBM software and hardware solutions, so that a unified data center architecture, based on zSeries and running Linux and WebSphere can handle your entire application domain.

Web Services
Web Services are abstract entities that encapsulate business logic using XML for discovery, description, and communication. In the example of a J2EE backend and a .NET frontend, a Web Service layer can be introduced that wraps the business logic of the WebSphere backend and makes it accessible to the .NET frontend. Communication between the two should be transparent. This form of architecture is called loosely coupled. A major selling point and strength of the WebSphere Application Development environment is just this - easing the service orientation of the business assets that are deployed on WebSphere.

However, it should be noted that while a loosely coupled, standards-driven architecture should make interoperability easy, in practice varying interpretations of standards have meant that Web Services written in one language on one platform don't always understand those in another language on another platform. Also, Web Services incur a large performance overhead, so while it may be tempting to wrap high-performance EJBs running on a zSeries platform in Web Services to expose them to other applications, you may lose the benefits of the technology and the platform with the overhead that you incur. From the management point of view, the following observations are made:

• 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 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 address 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 needing 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.

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 frontend presentation tiers are developed using ASP.NET and the backend business logic and data management tiers are implemented on WebSphere, 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 suffers from challenges insofar as management is concerned.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...