A single-node autonomic manager is responsible for the control of a single managed entity. A typical enterprise system is comprised of a large number of interconnected components. In an autonomic system, that translates to a large number of autonomic managers that need to interact with each other to exchange sensor data, policies, and perhaps plan a collective course of action to meet high-level business objectives. The topology of such systems may be hierarchical, peer-to-peer, or a combination of the two. Figure 3 depicts a hybrid system where groups of autonomic managers are organized in a hierarchical manner, with some elements of hierarchy being hierarchical groups of autonomic managers themselves, while constituents of other groups are connected to their peers.

In a hierarchical organization, each group has a "root" node that acts as the next level in the hierarchy. It typically aggregates instrumentation and events from members of its group and translates group-level policies into individual node policies or action plans. The "root" of the tree interfaces with the IT administrator who conveys policies and business objectives for the system. The overall goals and objectives are translated by the root-level autonomic manager into policies and execution plans for autonomic managers that are lower in the hierarchy.

Given the potentially large number and heterogeneity of autonomic managers, construction of large autonomic systems depends on the presence of well-defined standard interfaces for their interaction. Web services have proven their usefulness for construction of heterogeneous distributed computing systems since they are platform independent and support run-time discovery, introspection, description, and binding of components. Moreover, Web services are supported by leading software vendors and open-source projects resulting in built-in run-time support and availability of tools for both Windows* and Linux* environments.

Due to historical reasons, two major initiatives evolved to define mechanisms and standards for monitoring, controlling, and eventing using Web services for systems management, WS-Management, and WSDM. WS-Management [6] is a specification standardized by the Distributed Management Task Force (DMTF). It is built on three fundamental specifications: WS-Transfer [21], WS-Eventing [22], and WS-Enumeration [23]. WSDM [7] is a specification standardized by OASIS, which builds upon the Web Services Resource Framework, and WS-Notification. In the next few paragraphs, we briefly describe the scope and functionality covered by these specifications and outline a path to unifying these two approaches as identified in a white paper [8].

WS-Management utilizes the services of WS-Transfer for performing basic management operations on managed entities: Create, Read, Update and Delete (CRUD) by using WS-Transfer, which provides a generic set of CRUD operations for Web services. In systems management, numerous operations need to enumerate large lists of objects. For example, a remote manager may desire to list all the running processes on a machine in order to determine if there are any unauthorized processes. WS-Enumeration, which provides a set of generic operations to enumerate lists, can be used to iterate all instances of the CIM_Process class to obtain this information in an efficient manner.

WS-Management relies on WS-Eventing to provide the basic publish/subscribe/deliver semantics. A common interaction pattern in systems management is event-based interaction using a publish/subscribe mechanism. In this approach, an event source or its proxy makes known or publishes the type of events that it can generate. Entities indicate their interest in being notified when specific events occur by subscribing to them. The act of subscription consists of storing a subscriber's identity and notification address in the event subscription list maintained by the publisher or a suitable proxy. When events occur in the course of a monitored object's operation, the publisher notifies active subscribers. Publish/subscribe serves as an effective flow-control mechanism: no notifications are sent for events that nobody is subscribed to (they may be cached or logged) and subscribers are notified only about the events that they have explicitly stated interest in.

In the management domain, some objects may have a large representation, making it inefficient to obtain the entire set when only a subset of the information is required. To satisfy this requirement, WS-Management provided for enhanced operations to perform CRUD operations on partial object representations. In the case of events, WS-Eventing defined only a basic "push" delivery mode for the delivery of events. WS-Management defined enhanced delivery modes such as a batched mode, wherein the publisher or its proxy batches a specified set of events before sending them to the subscriber, thereby enhancing the ability of the subscriber to deal with a larger set of event sources.

WSDM and Web Services Resource Framework (WSRF) were devised in the Global Grid Forum community to handle stateful resources and then they moved to OASIS, as they were applicable to the broader Web services community. WSDM consists of two parts: MUWS, which defines basic management operations for managed resources and MOWS, which addresses the management of Web services. WSDM builds upon the WSRF, which provides details on how to represent and access the XML representation of a stateful resource [24]. The eventing communication paradigm for WSDM builds on WS-Notification (WSN) [25] and defines a standardized event format called WSDM event format [13].

The two specifications have a similar scope, use similar architectural approaches, and both rely on Web-services technology, resulting in both overlap and synergies between the two approaches. Having realized this, the authors of the two specifications started working on a common unified approach that would increase interoperability among components of management systems in general and specifically facilitate automated machine-machine communication such as between autonomic managers. This work is described in a white paper published in March 2006 [8], which outlines a roadmap for unifying the two approaches. The approach is to consolidate the underlying access (CRUD) to resource representations and eventing by defining two new specifications called WS-ResourceTransfer, WS-RT [26] and WS-EventNotification, WS-EVN (not yet published). WS-RT builds upon WS-Transfer and WSRF and provides mechanisms for performing CRUD operations on partial object representations. WS-EVN builds upon WS-Eventing and WSN by providing support for enhanced filtering on events, policy-based subscriptions, and treating subscriptions themselves as resources that are operated upon by using WS-RT semantics (this simplifies the processing of subscriptions as they are treated as managed resources and can be operated upon using CRUD semantics). Building upon the unified resource access and eventing mechanisms, the authors intend to define a common unified management profile, which will provide a common Web-services-based external access to autonomic elements.