The work being done in WSDM will lay a firm foundation for effective distributed system management, both leveraging the unifying strengths of Web services in the solution itself and addressing the specific requirements for managing what are rapidly becoming the universal glue in enterprise system design.

The OASIS Web Services Distributed Management Technical Committee (WSDM TC) was chartered in March 2003 to recommend standards to address a problem that has been developing for many years. But with the widespread emergence of Web services and service-oriented architecture implementations in mainstream enterprise IT environments, the distributed systems management problem can no longer be ignored. The WSDM TC is focusing on two distinct tasks as it attempts to solve some pressing distributed system management problems.

The first activity area, called Management Using Web Services (MUWS) addresses the use of Web services technologies as the foundation of a modern distributed systems management framework - including using Web services to facilitate interactions between managed resources and management applications. The same characteristics that make Web services successful for application integration make them an excellent choice for use in solving the management integration problem - facilitating communications between managers and resources across numerous vendors, platforms, technologies, and topologies.

In addition to the use of Web services in the creation of a management framework, WSDM is addressing the specific requirements for managing Web services like any other IT resource. This activity is called Management of Web Services (MOWS). The manageability models that are being developed for Web services will be exposed using the techniques defined as part of the MUWS task.

Web Services Accelerate a Problem
For over two decades, there has been an evolution underway in the architecture of enterprise IT systems - a move away from big, unwieldy monolithic systems toward distributed architectures. Technologies such as DCE, CORBA, and DCOM were attempts to standardize mechanisms for software system interoperability. Client/server architectures - two-tier, three-tier, and then n-tier - were stepping stones along the path to what is rapidly emerging as the dominant form of enterprise IT system design - the service-oriented architecture (SOA).

The SOA is a distributed system made up of software components that interact by passing messages to discoverable service access points. The SOA stresses interoperability, location transparency, and loose coupling.

While most consider the SOA an evolutionary step in the long road toward enterprise-scale distributed computing, the rate of adoption of SOAs based on Web services technologies is nothing short of revolutionary. This revolution is being fueled by the unprecedented vendor support of Web services standards. Web services deliver the required messaging and discovery building blocks for enterprise SOA deployments.

As Web service-based SOAs spring up across the enterprise landscape, they are accelerating and exacerbating a systems management challenge that has been growing in urgency in parallel with the development of enterprise-scale distributed computing.

In a monolithic application (or tightly coupled, client/server application), application boundaries are relatively clear and fixed. In an SOA environment, applications cross system (and even organizational) boundaries, they overlap, and they can change over time (see Figure 1).

Managing these applications is a serious challenge - but an absolute requirement. Failure or change of a single application component can bring down numerous interdependent enterprise applications. The addition of new applications or components can overload existing components, causing unexpected degradation or failure of seemingly unrelated systems. Application performance depends on the combined performance of cooperating components and their interactions.

Effective systems and application management in a Web service-based SOA requires a management framework that is consistent across an increasingly heterogeneous set of participating component systems, while supporting complex aggregate (cross-component) management use cases, like service-level agreement enforcement and dynamic resource provisioning.

The rapid emergence of Web services and their acceleration of SOA adoption have made this need urgent - resulting in the charter of WSDM in March 2003.

Basic Structure and Components
Figure 2 highlights the basic structure and components of today's management frameworks. This generic model will be used to highlight the specific areas of management being addressed by WSDM and how they differ from traditional models.

At the bottom of the framework is a managed system that contains a collection of managed resources. A managed system typically contains multiple managed resources - for example, CPU, memory, disks, software components, and Web services. In an SOA, a key management framework requirement is the ability to understand the relationships between managed resources both within and across system boundaries. Management systems today do a relatively poor job of building, maintaining, and leveraging information about resource relationships - particularly across managed system boundaries.

Next up the stack is the management agent. This component models managed resources and represents these resources in interactions with a manager. The manager always addresses and interacts with the management agent. The agent then interacts with managed resources.

A management protocol is the communication channel between the manager and the management agent. A management protocol is usually a two-way communication channel that allows the flow of operation requests and responses (e.g. get, set, and stop). It may use the same channel for passing notifications of events of interest.

In the distributed systems management context, it is increasingly important for management agents (and supporting management protocols) to define and support active capabilities versus traditional passive capabilities. For example, rather than merely raising an alert when a given Web service is unable to meet the performance requirements of a given service-level agreement, the management framework should be able to take corrective action. This action could take the form of rerouting requests to a backup service that is less heavily loaded, or provisioning a new application server with an instance of the software providing the service if no backup is currently running and available.

The manager is an application that communicates with management agents via management protocols, gathering information about managed system and managed resource status and performance, and supporting specific management tasks (e.g., root cause failure analysis, SLA monitoring and reporting, and capacity planning). It is this set of supported tasks that should drive (and is driving in the case of WSDM) the requirements for the rest of the management framework.

Existing Standards and Solutions Do Not Address the Problem
System and application management considerations have always been secondary to the creation and introduction of new systems and applications.

Management standards and solutions typically trail the introduction of new approaches to IT system design. Over time, the result has been a proliferation of fractured, simplistic management standards and proprietary solutions that are usually targeted to solve point management problems. These point solutions have been specific to managed resources (e.g., storage, network infrastructure, software applications), management problems (e.g., failure detection and analysis, performance management, security policy enforcement), or specific vendor or technology solutions (J2EE application management, Windows server management).

In a world of complex distributed systems, these no longer suffice. To effectively manage a distributed application there must be a uniform mechanism for consistently managing its constituent components; understanding and managing component relationships; and managing the resulting aggregate system as a whole. In addition, emerging customer requirements for autonomic computing capabilities require management solutions to be far more active in nature - solving problems, not just identifying them. Management systems must be able to do all of these things for applications and systems across the enterprise, and across enterprise boundaries.

WSDM addresses many of these traditional management solution shortcomings (e.g., lack of integration across vendors and platforms, end-to-end information collection, agent dependency and passivity) through two distinct focus areas as highlighted in Figure 3.

Management Using Web Services (MUWS)
WSDM MUWS activity focuses on defining how Web services architecture and technologies can be used to manage any IT resource. In particular, MUWS will define how to describe the manageability capabilities of managed resources using WSDL documents.

An overarching requirement for MUWS is that it must use existing Internet infrastructure technologies and be compliant to the Web Services Architecture developed by the W3C WSA Working Group. Many current MUWS contributors were original contributors to W3C WSA activities - where management requirements and issues related to Web services were initially laid out.

Web services technologies offer substantial advantages in the context of distributed systems management. They are language and platform neutral. There is tremendous industry momentum and support across a wide variety of system offerings. They offer on-the-wire interoperability and resource discovery with extensibility, separation of interface and implementation, and a rich metadata mechanism. In short, they allow MUWS to concentrate on developing specifications for problems specific to distributed systems management that require this set of infrastructure capabilities, without reinventing them.

There are two activities MUWS is not engaging in.

MUWS is not creating Web services technologies outside the scope of management. Required platform technologies will be obtained from the Web services community in the form of existing standards, specifications, and best practices. Examples are security, policy, and reliable messaging.

MUWS is not creating a new model for representing managed resources. Rather, the requirement is that MUWS must be able to work with multiple, existing, domain-specific models. CIM from DTMF is the most prominent, but not the exclusive, model for this work. SNMP and OMI information models will also be considered. The objective is to bind a unifying layer on top of these various models to facilitate consistent management in a heterogeneous distributed environment. This on-the-wire unification of disparate resource models is the real power of Web services in the management context.

There is a variety of functionality requirements that the MUWS recommendation must address, including (note that these were preliminary as of July 2003):