Web Services Management Strategy | Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices

The flexibility of Web services is now spreading across data center environments to simplify management of heterogeneous IT landscapes. Two management specifications, the Web Services Management (WS-Management) [WS-Management] and Web Services Distributed Management (WSDM), are similar in nature. Both of them share the common goal of uniquely identifying managed resources and monitoring resource status and can be leveraged to accomplish interoperability across Java EE and .NET applications. On the Java side the Web services Connector for Java Management Extensions (JMX) Agents, defined by JSR 262, intends to define a JMX Remote API to use Web services to transmit management information [JSR262]. This JSR may support WSDM and WS-Management. The chapter discusses how to apply each of these standards to realize management of Java EE and .NET applications.

Web Services Distributed Management (WSDM)

The OASIS WSDM standard consists of two specificationsManagement Using Web Services (MUWS) and Management of Web Services (MOWS). WSDM defines a management capability, which is a composable set of operations, events, metadata, properties, and other semantics. The rationale behind composability is to be able to scale up or scale down the management task.

In a nutshell, the first specification, WSDM MUWS, outlines details of representing and accessing resources across heterogeneous IT environments. With WSDM MUWS, every resource has a unique Identity capability, Metrics capability, and a few more. For discovering and advertising resources, WSDM supports an Advertisement capability, used for notifying availability of a new manageable resource. To discover additional resources, WSDM supports Relationships among resources; whereas, for querying a resource registry, WSDM supports Registration events. MUWS defines an Operational Status capability retuning an Available, Unavailable, or Unknown status of a resource and also defines a State capability for managing the resource lifecycle.

The second specification, WSDM MOWS, extends MUWS with details on how to manage a resource represented in the form of a Web service. A service that is managed has Identification. MOWS defines numerous metrics such as ServiceTime, NumberOfSuccessfulRequests, and NumberOfFailedRequests to gather statistics of individual services. An Operational State of the managed service can be Up, with either Idle or Busy sub-states, or Down with Stopped, Crashed, or Saturated sub-states. If all services are Up, the OperationalState capability defined by MUWS, returns status Available; if all services are Down, the state indicates Unavailable. A Request Processing State defines what events to be taken when a request state changes.

To accomplish the management capabilities, WSDM relies on various Web services specifications including WS-I Basic Profile, WS-Resource Framework (WS-RF) Resource Properties (WSRP) for properties, WS-Notification (WSN) Base Notifications (WSBN) for management event transport, and WS-Addressing (WSA) for Web services references. Refer to [WSDM] for more details.

How does WSDM relate to Java and .NET application management? WSDM MUWS supports SOAP over HTTP, XML schema for data type definition, and WSDL for interface definition. JMX and WMI APIs can be used to instrument a business application, whereas MUWS can be used as a communication mechanism between business applications and management systems. This strategy can be accomplished by using custom, or a third-party adapter that would perform the mappings between WSDM and corresponding APIs, such as JMX or WMI. This strategy is demonstrated in Figure 15-4.

Figure 15-4. WSDM-based strategy

To learn more details about this approach and specifically on how to integrate JMX with WSDM, please refer to [JMX_WSDM]. MUWS can also be used in conjunction with SNMP, CIM, and other management frameworks. Because WSDM supports an agentless architecture, both proxy and agents can be used when deploying a WSDM-based solution.

Benefits and Limitations

The fact that WSDM became an OASIS standard, regardless of dependencies on various evolving specifications such as WS-Resource, WS-Addressing, and WS-Notification, is one of its biggest drawbacks. As of now there are no commercial implementations of this specification.

Despite its ability to integrate WSDM standards with Java and .NET, this strategy presents some difficulties. One-to-one mapping between MBeans and WSDM Manageability endpoints may result in an overwhelming amount of information to be processed. Another constraint pertains to the data type mismatch between Java and WSDM defined data types as well as C# or other .NET languages and WSDM types.

WSDM Implementations

HP has donated code for three Web Services Distributed Management (WSDM) 1.0 specifications to the Apache Foundation to eventually provide developers with an open source Java implementation of the WSDM standard. The three specifications include

Management Using Web Services to represent a management interface or a resource in the form of Web services, see [Muse_Apache].
Web Services Notification describing how to send management information, see [WSN_Apache].
Web Services Resource Framework defining a way of exposing and representing managed resources such as CPU consumption and memory utilization, see [WSRF_Apache].

WS-Management

WS-Management is rapidly gaining popularity and is expected to have wide support from industry leaders such as Sun, Microsoft, and Intel. WS-Management (WSMAN) 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. The goal of WSMAN is to allow interoperability across managed applications and resources, which is in essence very similar to WSDM. WSMAN is designed to be applicable to small, memory-constrained devices; hence, compared to WSDM, WSMAN is a simpler way to implement a management solution and requires a minimal set of components to implement to comply with the specification. Any WSMAN-compliant device such as a baseboard management controller (BMC) can be managed via WS-Management. WSMAN also can be applied to manage Web services as well as applications. 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.
Enumerate the content of containers and collections including large tables and logs.
Subscribe to events emitted by managed resources.
Execute a management method with strongly typed input and output parameters.

To discover management resources, the WSMAN uses the WS-Management Catalog specification, which defines metadata for managed resources. The WS-Management Catalog contains details 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 identifier, and name/key value pairs identifying a resource. Managed resources are grouped into Systems; one or more Systems comprise a Service. Management services expose Web service 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.

At the time of writing this chapter, there is no direct mapping between WS-Management and WMI or JMX APIs available in industry, although some work has been initiated by Sun. The initial set of implementations extends the WS-Management specification with mapping to the Common Information Model (CIM) schema. CIM specifies a common definition of management information for systems, networks, applications, and services to allow heterogeneous environments to adhere to a consistent management standard. A common way to represent CIM classes is by using the Managed Object Format (MOF). On Windows, the MOF compiler adds corresponding classes to the WMI repository. The Microsoft WMI Administrative Tool includes WMI CIM Studio component to create and manage classes, properties, and instances. The tool also facilitates generation and compilation of MOF files. See [WMISolutions] and [WMITools] for more details. With JMX, a managed client application can access MBeans using CIM/WS-Management, where CIM defines semantics of the data (what) being transferred and WS-Management outlines semantics of the communication (how) protocol between the client application and distributed resources. Figure 15-5 outlines a potential strategy to utilize WS-Management specification in a heterogeneous Java EE .NET domain.

Figure 15-5. Java EE .NET Application Management with WS-Management

JMX is a natural back-end technology for incrementing WSMAN resources in Java. Sun is in the process of prototyping a WSMAN adaptor that makes it possible to implement WSMAN resources using JMX MBeans.

Co-developers of the WS-Management specification have announced their intention to present the specification to the Distributed Management Task Force (DMTF).

Benefits and Limitations

There is a clear desire among various industry players for WSDM and WS-Management to converge into a single specification. WS-Management is gaining popularity among various vendors, and it is simply a matter of time before it gets widely adopted by various hardware and software vendors. Benefits of cross-industry adoption would help to enable heterogeneous devices and applications to communicate their status using universal language defined by WS-Management.

In terms of interoperability, the main limitation is the lack of WSMAN adapters for JMX, which should be solved in the near future.

Example

Sun has published an open source implementation of the WSMAN specification (see [WISEMAN]).

In the WS-I Supply Chain Management application, a .NET application exchanges a PO message with a Java application. Should the physical machine on which the Java application is deployed fail, this failure could typically be manifested at the application level via a SOAP Fault received by a .NET component. With WS-Management, a Microsoft Management Console or a SharePoint Service would receive detailed information regarding the hardware failure and required remedial actions. In this scenario, management of interoperable environment can be easily addressed by repairing the hardware problem without a need to troubleshoot the problem at the application level.

Commercial Solutions

Microsoft Windows 2003 R2 includes the WS-Management Service for hardware-level support. WBEM Solutions plans to support WSMAN in both the J WBEM Server and C WBEM Server products later this year. See [WBEMSolutions] and [Win2003_WSMan] for details.

Management of Web Services

Both WS-Management and WSDM define a way to manage resources by using Web services as well as a way to manage Web services. For the latter, there are number of Custom Off The Shelf (COTS) solutions available to monitor Web services deployed in a distributed environment. See [WSMgmt] and [WSMgmtStandards] for an overview of various elements involved in Web services lifecycle management. Most of the commercial solutions address not only monitoring of the system performance, availability, and throughput, but also provide auditing and reporting functionality. Web services deployment and dynamic problem troubleshooting are often key features offered by commercial management solutions. Various products support both agents and proxy based deployments depending on the requirements. These products are available from Actional, AmberPoint (which provides both Java and .NET implementation of the SOA management solution), Flamenco Networks, and Systinet. AmberPoint Service Level Manager can track SLAs and send events to MOM in case monitored Web services experience performance or availability problems. AmberPoint also offers integration with enterprise monitoring solutions such as HP OpenView. See [ActionalSoapStation], [Systinet], [AmberPoint], [FlamencoNetworks] for detailed solution features. Among Web services management solutions, CA Unicenter WSDM (CA WSDM) Management Pack provides Microsoft Operations Manager 2000 with the ability to monitor Web services across Java EE and .NET applications. Refer to [CA_WSDM] and [CA_WSDM_MOM] for more information.

ISO Characteristics in the Web Services Management Scope

This section discusses ISO characteristics in the context of Web services management.

Fault Management The MOWS and WS-Management requirements address functionality for problem detection, root cause failure diagnosis. Web service standards do not guarantee Java EE-.NET encoding coherence both for complex data types as well as for several primitive data types, which can lead to hard-to-track failures [IBM2].
Configuration Management The WSDM functionality supports notification of service changes. The MOWS requirements specifically address service deployment and life cycle management.
Accounting Management The MOWS requirements address the functionality of service metering and auditing and integration with billing and SLA management.
Performance Management The overhead of XML processing and SOAP/HTTP is considerable, especially as compared with binary wire formats such as used in the bridging solutions described previously. SOAP messages are relatively large, often requiring a great deal of metadata, and parsing and validation effect through put and performance [BIJ1]. Performance metering is addressed in the MOWS requirements.
Security Management Because WS-Security supports different styles of authentication and encryption protocols, it is possible for endpoints to be WS-Security-compliant but still not have a common protocol between them. WS-Security is a more robust model than HTTPS transport-level security but can significantly impact performance and response time [IBM3].

Because SOAP is a multi-hop protocol, user credentials need to be managed and synchronized across all the Web service platforms in the application. PKI-based approaches can use SAML for a more robust solution but introduce the complexity of PKI management for all of the systems. Implementation of the WS-Trust and WS-Federation specification provide a Web services standard for propagation of trust and federated identity management. However, management problems such as role and attribute mapping between systems for authorization remain unsolved. It is possible for attributes assigned to a user in one system to have a different meaning in an interoperating system [GFMP].

Web services is not the only means to mitigate system management risks across Java EE and .NET environments. The Unification strategy, discussed next, is another way companies address management challenges. With this strategy the underlying platform is unified for both .NET and Java EE applications using Mono platform. See [Mono] for more details.