Web Services Web Services Management: A Standards-Based Common Architecture Part 2

Web Services Management: A Standards-Based Common Architecture Part 2

As enterprises rush to deploy Web services-based solutions, problems in managing the services are becoming a challenge to their success. In a service-oriented world, service level assurances are the need of the hour—implying services need to be “managed” well. It is important to understand what Web services manageability means to a business, an administrator, and an end user. Equally important is to design an infrastructure that can work across existing platforms and can interoperate with existing standards.

In the first article of this two-part series, we discussed the expectations from a Web services management platform and the standards relevant to Web services management. Based on this analysis, let us propose a common architecture for Web services management.

Web Services Management Architecture

In the light of the features, requirements, and standards identified, the following architecture is proposed for Web services management. Subsequent to the diagram is a discussion on the architecture, including an explanation of the roles of various architecture components.

Figure 1: Common Architecture for a Web Services Management Infrastructure

Architecture Discussion

The architecture proposed is based on:

  1. The requirements elaborated in the section titled “Functionality expected from Web Services Management Infrastructure.”
  2. The standards recommended in the section titled “Industry Standards.”

The following components and their interactions are shown in the architecture diagram above.

  1. Web services clients: These are common Web services client applications that access Web services, typically using a SOAP protocol over HTTP. The users of Web services would have agreed upon some QoS for accessing these services from the Web services providers.
  2. Operating system: The operating system on which the Web services platform is deployed. This has some management information relevant to Web services management, which it gives out in CIM/XML format. Some operating systems, such as WindowsTM NT and HP-UXTM, already support some aspects of WBEM (CIM/XML/HTTP) for OS management.
  3. Web services platform: The platform, which hosts the Web services, makes them accessible to the Web services clients and controls their life cycle. This is instrumented to send and receive management information relevant to the functionalities it supports. The format for this data could be CIM/XML, JMX, SNMP, or any other proprietary format.
  4. Web services: The services that provide some concrete business functionality to the Web services clients. These are deployed on and run within the Web services platform environment. They use the platform hooks to instrument themselves, thus enabling the sending and receiving of management data at runtime. The data, again, could be in CIM/XML, JMX, SNMP, or any other proprietary format.
  5. Management data adapters: These adapters are used in conjunction with Web service platforms. Their purpose is to convert the management information emitted by the platform and the Web services deployed on them from any format to CIM/XML standards and vice versa. Because these adapters work with platform-specific data formats (whether it is JMX, SNMP, or any other), they are expected to be developed by the platform vendors. The exact CIM/XML bindings for each piece of information have to be defined by a standards body, and these can be used by the adapter developers, as also the management server developers. The standard CIM/XML data is then communicated to and from the Web services management servers.
  6. Web services management servers: These servers mediate, process, and persist the Web services management data, ultimately providing the monitoring and control functionalities to the Web services. They receive management data from the Web services platforms (possibly via adapters) to process, store, and/or send it for display. They also receive control information from the management consoles and send appropriate management data to the Web services platform to manipulate the platform or the services deployed on it. The data to be displayed on consoles can be generated by applying stylesheets over the CIM/XML management data coming from the Web services platform.

    A management server may also include an implementation of CIMOM (CIM Object Manager) for Web services. A CIMOM is a central dispatching and facilitating process, which intermediates between management applications or consoles, a data repository, and individual data sources. CIMOM is also part of the CIM specification.

  7. Web services management database: This is an optional data store for management information used by the Web services management servers.
  8. Notification engine: A notification engine is necessary for propagating management events from the management servers to the management consoles or PDAs. They are particularly useful in scenarios where events can’t be pushed easily to management clients (for example, WWW browsers). A management server would push event notifications to this engine, which would then propagate them to various consoles in a console-specific way; for example, to PDAs via a device gateway. Event correlation can also be built into this engine.
  9. Web services management consoles: The Web services management consoles (browser/PDA-based) act as interfaces for Web services management administrators, allowing them to monitor and control the Web services platform—thus ensuring that the SLAs with the Web services end users are obeyed and QoS is guaranteed. The consoles can also be used to administer advanced Web services management functionalities as mentioned before. The consoles receive information from the Web services managements servers, possibly over the Web. Administrators can also use the consoles to issue management commands to Web services platforms (via the management servers) for configuring and manipulating the platform and the Web services deployed on it at runtime.

The Complete Picture

To put the above architecture proposal in perspective, it is imperative to discuss how the current Web services and IT management scenario can evolve to this model of management. Let us look at what else needs to happen apart from implementing and installing management infrastructure based on the architecture proposed in this paper.

First, let us understand that a Web services management infrastructure is targeted at administrators in an IT organization. However, current IT administrators are trained more for hardware, storage, and network infrastructure management rather than software “application” management, which is what Web services management would involve. Some degree of re-orientation of the administrators might be needed. An additional complexity arises from the fact that some of the service-level parameters in Web services are much closer to business functions, and hence should be determined by people in business decision roles.

Secondly, Web services QoS, occasionally, would involve services outside a management domain (for example, in a composed service scenario). Software and hardware intermediaries for service provisioning also affect the service levels if end-to-end SLA guarantees are made. Having common schemas for management data accessible via standard protocols would help in integrating the management information across domains. But, guarantees across domains would have to be made more carefully.

Lastly, following are some more challenges to consider with respect to Web services management:

  1. Accessing Web services management data over the Internet will require a robust and end-to-end security environment during operation. Security standards and implementations for Web services are still evolving and will require industry-wide agreement before widespread adoption.
  2. Understanding the value in adopting common management standards by Web services platform vendors is needed. Companies will have to agree and adopt common standards which could potentially commoditize the platforms.

Existing Products

Let us briefly look at some of the related products that exist today. Current products available in the market are rudimentary from a management perspective and follow varied approaches to Web services management. They have different notions of what Web services management means and their implementations are very different and mostly proprietary. Also, the products themselves are evolving by providing more functionalities and better integration with Web services platforms. However, there is a need to standardize management functionality for multiple reasons. One, Web services themselves are based on open standards. Base services for the platforms, as in security, transactions, and so forth are also getting standardized. It doesn’t make sense for management alone to be proprietary. Secondly, open standards enable plug and play of components and ensure a level playing field for software vendors giving customers the best value by avoiding proprietary lock-ins.


This discussion guided us towards an open architecture for a Web services management infrastructure. An analysis of deployment realities, required features, and open standards formed the basis of this architecture.

Standards adopted in the architecture are CIM (Common Information Model) from DMTF (Distributed Management Task Force) and its XML/HTTP bindings in form of the WBEM (Web-Based Enterprise Management) standard. The rationale for choosing these standards is that they exhibit:

  • An extensible data model for management information
  • Suitability to a Web services management environment (HTTP(S) transport)
  • Loose coupling (XML encoding)
  • Prevalent adoption across vendors for management of OS, Applications, and so on

The architecture proposed is compatible with existing popular Web services platforms (J2EE-based platforms and .NET) as well as with future platforms. It allows enough scope for vendors providing Web services management products to compete by offering more and more management functionalities based on a framework of open and mature standards.

About the Authors

Pankaj Kothari is a technical lead at Hewlett-Packard, India. He has been involved in designing and developing enterprise middleware and Web services products such as e-speak and HP Application Server. He has also contributed to the architecture and implementation of solutions based on these technologies in various domains for more than five years. He can be reached at [email protected].

Ravi Trivedi holds a Masters degree in Computer Science from the Indian Institute of Science, Bangalore. He is a Technical Lead at Hewlett-Packard, Bangalore. He is an expert group member for HP in JAXR (JSR 93) and a committer for open source UDDI4j (www.uddi4j.org). He is involved in developing core Web services infrastructure and solutions based on these. He can be reached at [email protected].


We would like to acknowledge the contributions of Srinivas Varadarajan, Ashish Chitkara, Manoj Seth, Shyam Bijadi, and Jainendra Kumar at Hewlett-Packard, India for their insightful reviews.

Disclaimer: The views expressed here are those of the authors and does not necessarily represent that of Hewlett Packard.

Latest Posts

Related Stories