Marina Fisher, Ray Lai and Laurence Moroney are co-authors of .NET/J2EE Interoperability: Integration Strategies, Patterns and Best Practices with Sonu Sharma. Jeremy Barkan is an Enterprise Software Architect and has been writing, designing and architecting software for the past 20 years.
Monitoring quality-of-service across large-scale, distributed enterprises is difficult, especially when troubleshooting systems built from disparate technologies such as J2EE and .NET. Without an effective management infrastructure in place, troubleshooting can consume days or weeks before problems are identified and fixed, leading to system downtime or degraded service levels.
Deploying, configuring, monitoring, detecting, notifying and healing problems are the constituents of system management. The ultimate goal of system management is to ensure that the quality of service and operating requirements of all business applications are satisfied. In the ISO Network Management model (www.iso.org), the key elements of this complex task are fault management, configuration management, accounting, performance management and security management. Achieving these goals in a mixed J2EE and .NET platform environment presents many management challenges. An implementation of the Simple Network Management Protocol (SNMP), designed for network management, is available for Windows and various Unix platforms and can be leveraged to monitor platforms hosting mixed J2EE and .NET applications. SNMP is often used as the lowest common denominator to monitor nodes on IP networks and to provide detailed networking statistics. However, SNMP also produces lots of information that can be filtered.
In this article, we examine strategies for managing applications that require interoperability between J2EE and .NET. The first approach—using Web services—is well known, involving business processes that are surrounded by functionality exposing a standard interface. As communication occurs across this interface, the underlying technology implementation doesn't matter and interoperability is achieved. The second approach—Platform Unification—involves applications written on diverse platforms that interoperate by reducing diversity and having a single platform.
Managing Java and J2EE Applications
The Java Management Extensions (JMX) APIs enable instrumentation of Java applications and facilitates management of JMX resources (devices, services or business applications). The JMX component model introduces the notion of a managed bean (MBean) that 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 means of protocol adapters or connectors. Figure 1 outlines some of the core JMX components.
Managing .NET-Based Applications
Microsoft provides the Windows Management Instrumentation (WMI) framework for instrumentation and monitoring the operating system, frameworks and applications. Using WMI in a .NET application can be accomplished through System.Management and System.Management.Instrumentation namespaces. Applications built on either .NET or native code can be managed using these APIs. In addition to the WMI framework, the Microsoft Operations Manager (MOM) offers IT managers a way to administer OS-level services and Windows applications, including .NET-based ones. The Microsoft Management Console (MMC) is yet another administrative solution that enables management of Windows-based environments. In addition to this, the open-source MMC .NET library (http://sourceforge.net/projects/mmclibrary/) provides support for MMC snap-in development in C#. Lastly, Microsoft's Systems Management Server (SMS) assists users with patch management and software updates.
The Interoperability Technology Gap
Managing applications that are mixed mode—that is, having both J2EE and .NET-based components—raises a number of challenges. For example, JMX isn't interoperable with WMI, OSS/J doesn't work with applications built on the .NET platform, and the Microsoft Management Console can't control JMX Agents.
While there are technologies that manage application-level details for both technologies, such as AVICode for .NET (www.avicode.com/content/prod ucts/InterceptStudio.asp) and AutoPilot for J2EE (www.nastel.com/products/ ap_it.shtml)—there is no solution that monitors both. Granted, the WS-Management specification exists, but it isn't fully mature. If a system is architected where interoperability is achieved using Web services, then various Web services management solutions, such as those available from Amberpoint (www .amberpoint.com) or Actional (www .actional.com) can be used to manage the full system.
To complement this, an SNMP-based management solution collects and responds to low-level networking information once it has been interpreted into meaningful business messages.
ISO Application Management
According to the ISO, the requirements for managing applications that interoperate are:
- Fault management. There should also be a common logging system across the system.
- Configuration management. There should be a common method for managing the configuration of the front end, middleware and back end, and a consistent programming interface across all version changes.
- Accounting management. The system should provide metering to ensure that the warehouse systems fulfill the requirement for uptime, and to record the usage of the system per end-user.
- Performance management. The system should deliver acceptable response time for a user experience and ascertain how the system should react to performance metrics.
- Security management. The system should provide an authentication system that lets the front-end system authenticate the user at login, and allows the back-end system to trust the front-end authentication. There should be a single system for management of users, credentials, and their roles.
The two main strategies that can be used to manage infrastructures such as these involve:
- Using Web Services Management (WS-Management) and associated tools.
- Developing and managing the system using a Platform Unification strategy.
Web Services Management Strategy
The nature of Web services—abstracting the technological implementation of business functionality and allowing for accessibility through a standard interface—lends itself to clean management. Two specifications, Web Services Management (WS-Management) and Web Services Distributed Management (WSDM), make this possible. They share the goal of uniquely identifying managed resources and monitoring their status, and can be leveraged to accomplish management of interoperating J2EE and .NET-based applications.
WS-Management is gaining popularity and support is expected from organizations such as Sun, Microsoft, and Intel. WS-Management identifies a core set of Web service specifications and usage requirements to expose a common set of operations that are central to all systems management. Its goal is to allow interoperability across managed applications and resources and any compliant device, such as a baseboard management controller (BMC). There are five core operations highlighted by the WS-Management specification:
- Discover managed resources and navigate among them.
- Get, put, create, rename and delete resources.
- numerate the content of containers and collections including large tables and logs.
- Subscribe to events emitted by managed resources.
- xecute a management method with strongly typed input and output parameters.
To discover management resources, the WS-Management uses the WS-Management Catalog specification, which defines metadata for managed resources. The WS-Management Catalog contains de- tails on how a managed hardware or software resource is to be accessed via a WS-Addressing endpoint reference that includes a URL of the resource, the resource type iden- tifier and name/ key value pairs identifying a resource. Managed resources are grouped into Systems, one ore more Systems comprise a Service. Management services expose Web Services APIs defined by the specification to the client application that consolidates management information. Event notifications can be delivered to endpoints via multiple delivery modes, including batched and pull. Aside from WS-Addressing, the WS-Management specification also references WS-Eventing, WS-Enumeration, and WS-Transfer.
When implementing services, the interfaces are mapped to the Common Information Model (CIM) schema, which specifies a common definition of management information for systems, networks, applications and services to allow heterogeneous environments to adhere to a consistent management standard. Figure 2 (page 32) shows how WS-Management, using CIM, can be used in a mixed-mode Java/.NET application.
Co-developers of the WS-Management specification have submitted the specification to the Distributed Management Task Force (DMTF). This is a major step toward developing an interoperable distributed management standard.
On the other hand, WSDM, defined by OASIS, consists of two specifications: Management Using Web Services (MUWS) and Management of Web Services (MOWS). They define a management capability, which is a composable set of operations, events, metadata, properties and other information. A WSDM adaptor that publishes the appropriate Metadata for the service is necessary for each component, so that the component may be managed through a management console, as in Figure 3.
A clear benefit of this solution is that it is already an OASIS standard. Hewlett-Packard has donated code for three Web Services Distributed Management (WSDM) 1.0 specifications to the Apache Foundation (see http://ws.apache.org/ muse/, http://ws.apache.org/pubscribe/ wsn.html and http://ws.apache.org/ wsrf/). At this writing, we're not aware of any solutions for .NET.
Table 1 shows the implications of using the WS-Management and WSDM approach with regards to the ISO Characteristics. The WS-Management specification is designed with system management in mind, and has not been tailored for these characteristics. However, it can still meet some of these characteristics as noted in the table.
|
Table 1 ISO management characteristics of Web Services Management
Fault Management. These specifications address functionality for problem detection and root cause failure diagnosis. They don't guarantee encoding coherence for complex data types, which can lead to failures that are difficult to track.
Configuration Management. WSDM functionality supports notification of service changes. They specifically address service deployment and lifecycle management.
Accounting Management. The specifications address the functionality of service metering, auditing and integration with billing and SLA management.
Performance Management. The XML/SOAP processing that is necessary for WS-Management and WSDM is considerable. SOAP messages are relatively large, often requiring a great deal of metadata.
Security Management. The specifications support a number of different authentication and encryption schemes and protocols. It's possible for the endpoints to be WS-Security compliant but not have a common protocol between them. As such, security is a very positive factor of this approach. |
Platform Unification Strategy
An alternative methodology is to unify the platforms at design, development and runtime. The clear and easy way to do this, developing the entire system in a single language, be it .NET-based or Java in the typical case, isn't realistic, as many assets may have already been developed, and a mixed-mode architecture is common. However, Visual MainWin for J2EE (VMWJ2EE) from Mainsoft (www.mainsoft.com) lets existing .NET-based assets be recompiled, redeployed and run on J2EE.
For .NET code to execute in the J2EE environment, the code must be executable as compliant Java bytecode that runs in a Java virtual machine. An application written in a .NET language such as C# is compiled into a common language called Microsoft Intermediate Language (MSIL). The Mainsoft binary compiler converts this MSIL code into pure Java bytecode. This bridges the difference in .NET and Java semantics, while producing efficient and compliant code. This process can be seen in Figure 4.
Interoperability with Java Code from the .NET code is now handled natively. Because the runtime environment is Java-based throughout, interoperability between the two is simplified. For example, in a scenario where a service is implemented in Java using an EJB component, if a mixed-mode deployment is used, a Web services wrapper or similar interoperability layer would be necessary for a .NET component to communicate with it. This would lead to potential difficulties and performance implications. However, on a unified platform, the .NET components now rehosted on Java would be able to access the EJB directly.
This achieves a cross-language/ cross-environment platform with a uniform J2EE management model. Thus, the challenges posed by the mixed management models previously described are significantly reduced. In this model, the intercomponent communications are based on native protocols—such as Java method calls or RMI.
The Platform Unification model (Table 2) does not impose an architectural model on the components so they can be tightly (through RMI or the like) or loosely coupled (through Web services) depending on the needs of your application. This architectural flexibility allows a mixed .NET and J2EE system to be designed to meet the organizational structure, rather than be constrained by the interoperability technology. Additionally, .NET semantics are preserved for the developer, but the manager has a coherent J2EE management view of the system.
|
Table 2 ISO management characteristics in the Platform Unification Model
Fault Management. Monitoring, event handling and logging are implemented through underlying J2EE mechanisms. The .NET Systems.Diagnostics APIs for logging are implemented at runtime through the java.util.logging framework. JMX and logging APIs are also available to the .NET environment. End-to-end debugging and fault analysis are available.
Configuration Management. System management is simplified by a homogenous runtime. Tuning, updates and patch management can be performed on a homogenous system. Application management is typically done through a J2EE administration console across the entire platform (including the .NET components). Resources such as data sources and Enterprise services may also be managed uniformly through the J2EE console.
Accounting Management. An application deployed on a unified platform is managed through a single accounting management system running on J2EE. This reduces the complexity of managing service level agreements across different accounting systems on different platforms.
Performance Management. This approach has the key benefit of intra-component communications not incurring the additional overhead of wire protocol conversions, such as bridging or SOAP/HTTP Web services. Coherent statistics may also be collected through J2EE metering facilities.
Security Management. Under the Platform Unification model, the security model is provided through J2EE. The homogenous J2EE security model across the application, using either JAAS or J2EE security, allow for management of users and authorizations in a single domain. This simplifies management of security and eliminates the need for managers to synchronize users and authorizations across multiple domains. |
Conclusion
Effective management of any application platform shouldn't be an afterthought in the design or implementation process. It is a vital—and complicated—part of the process that becomes exponentially more complex as different technology implementations implement the system components. Ultimately, it is the role of the architect to explore all aspects of the system, including management.
