Managing Mixed Java EE and .NET Environments

IT managers regularly use distributed management systems to address Quality of Service requirements. Typical management systems can be agent-based, using standards such as SNMP or higher-level standards such as CIM (please refer to [DMTF] and [CIM]). Higher-level functionality at the system and application level requires platform-dependent management. The next sections explore management support offered by Java EE and .NET platforms.

Management of Java Applications

The Java Management Extensions (JMX) APIs (see [JMXIntro] and [JMX_WP]) enable instrumentation of Java applications [JMAN] and facilitate management of devices, services, or business applications referred to as JMX resources. The JMX component model introduces the notion of a managed bean, MBean, which represents managed resources. Resources instrumented with MBeans represent the key component of the JMX architecture. These MBeans are registered and deployed within an MBean container that is part of a JMX agent. An agent also includes services for controlling MBeans and consolidating information gathered by MBeans into a remote management console. Finally, the JMX Agent is accessible to a remote management console by means of protocol adapters or connectors.

JMX is available for download, [JMX_Download], and accessible in the form of javax.management libraries. The diagram in Figure 15-1 outlines some of the core JMX components.

Figure 15-1. JMX overview

The JMX 1.2 specification consists of three layers: the Instrumentation layer, the Agent layer, and a Distributed layer. The Instrumentation layer encompasses resources such as applications, devices, or services instrumented using MBeans. The Agent layer contains an MBean Server along with additional services such as monitoring. A Distributed layer contains adapters and connectors to remotely access JMX agents [JMXIntro].

JMX represents a key management capability in Java. It is used for management of Java EE application servers, JSR-77, and compliant Java EE applications, JSR-88. Java Virtual Machine Profiling API, implemented in Java 5 improves a virtual machine profiling interface, [Java5Mgmt], and a way to enhance the JVM control. Java SE 5 is shipped with a console application, jconsole, aimed for basic troubleshooting purposes.

Aside from JMX, the Operations Support Systems (OSS) through Java Initiative (OSS/J), defines a standard set of Java APIs to enable compatibility across OSS systems. See [OSSJ] for more details. OSS/J includes the Service Quality Management API, Quality of Service API, and others that mitigate manageability risks of an enterprise system. The OSS/J initiative, which is part of the Java Community process, embraces multiple industry vendors and provides Java APIs to allow a consistent method for managing services.

Management of .NET Environment

Microsoft Windows provides the Windows Management Instrumentation (WMI) framework for instrumentation and monitoring of the operating system, frameworks, and applications [WMI], [WMIGuide]. Using WMI in a .NET application can be accomplished through System.Management and System.Management.Instrumentation namespaces. Both .NET managed applications and native code can be managed using these APIs. In addition to the WMI framework, the Microsoft Operations Manager (MOM) solution offers IT managers a way to administer OS-level services and Windows applications, including .NET. Another administrative solution from Microsoft called Microsoft Management Console (MMC) enables management of the Windows-based environment. An open source MMC .NET library is available from sourceforge.net [MMC_.NET] and provides MMC snap support for C# development. Another Microsoft management solution, Systems Management Server (SMS), assists users with patch management and software updates, [SMS].

Interoperability Technology Gap

Java EE .NET management interoperability embraces a number of interesting challenges. Java Management Extensions (JMX) is not interoperable with WMI, and OSS/J does not span across .NET platform. Microsoft Management Console cannot control JMX Agents.

To determine application-level crashes during development with .NET-based technologies, Microsoft leverages AVIcode Intercept Studio to extend MOM with application manageability. See [Avicode]. There are a number of commercial solutions to monitor Java EE such as Nastel's AutoPilot/IT that is actually based on JMX technology. See [AutoPilot] for more details. A gap that still needs to be filled is a commercial solution to monitor both Java and .NET applications.

WS-Management is gaining momentum and will eventually provide cohesive means to manage devices, systems, and applications; however, Java EE and .NET developers cannot leverage WS-Management today for interoperable application management.

At the systems level, Microsoft Operations Manager does not support the Java EE platform. Microsoft Operations Manager has commercial extensions, such as Vintela System Monitoring, that provide heterogeneous management of Windows, Solaris, Linux and Mac OS X environment. See [VSM]. Similarly, heterogeneous OS level management can be achieved with commercial extensions, such as Vintela Management Extensions, which enables Microsoft Systems Management Server (SMS) 2003 with the capability to support Solaris, Linux, and Mac OS X. See [VMX] and [VINT] for more details.

With an SNMP-based management solution, low-level networking information has to be interpreted into meaningful business messages. An intermediate solution is required for aggregating and filtering the QoS notification.

Agent and Proxy Management Deployment Architectures

Two prevalent architectures deployed for managing enterprise systems are agent-based or proxy-based. With an agent-based architecture, proprietary management software agents have to be deployed across managed systems. This requires additional installation, synchronous updates, and is not as transparent as a proxy-based architecture. The latter relies on a proxy acting as a broker between a centralized management console and distributed managed systems. With agentless proxy architecture, the main drawback is that the proxy often becomes a single point of failure for the entire management chain, as the proxy is the only link between managed resources and the management console. Figure 15-2 outlines agent and proxy-based architectures.

Figure 15-2. Agent and proxy-based management architectures