Web Services Management: A Standards-Based Common Architecture, Page 2
Functionality expected from the Web Services management infrastructure
Let us go into the details of what is expected from a Web Services management infrastructure—including what is not so obvious from the hosting scenarios. These requirements will lead us to a proposal on the Web Services management architecture.
- As mentioned above, Web Services management can be done remotely—even across the Internet. This means that management information preferably must travel over a HTTP(S) protocol.
- The management information should be able to be processed by another application using open APIs or data handlers. Data handlers, in this case, are typical loosely coupled XML document processors. This enables plugging in independent components to take appropriate action based on the state of the Web Services ecosystem.
- The management technologies and products must be agnostic to the Web Services platforms: It is reasonable to expect that an administrator will manage Web Services deployed on platforms as varied as MicrosoftTM .NET or any J2EE-based Web Services platform, for example, BEA's WeblogicTM server—sometimes a mix of them at the same time. So the management infrastructure needs to be capable of handling all Web Services platforms as long as their management information has a compatible data format and this information is transported over a common protocol.
- There are existing standards in the management domain. SNMP4 is a protocol widely used for managing network devices. JavaTM Management Extensions (JMX) from Sun Microsystems is an open technology for management of Java based enterprise software components. DMTF (Distributed Management Task Force) has defined the Common Information Model (CIM), which is a common data model of an implementation-neutral schema for describing overall management information in a network/enterprise environment. It would be desirable that a Web Services management infrastructure reuses these standards, so that information of other components in the ecosystem (that already use these standards for management information, for example, the OS and network devices) and information of the new Web Services components can be processed and presented in a common way to the administrators. Thus, the existing investment in IT management can be preserved. Also, the maturity of existing standards can be leveraged by adopting them.
- Key functionalities: The basic functionalities of a Web Services management product would be:
- Platform monitoring: Monitoring and reporting the status of the Web Services platform—for example, whether the platform is running or stopped, whether more Web Services can be deployed on the platform, and so forth.
- Service monitoring and provisioning: Monitoring and reporting the status of the Web Services deployed as part of a business application—for example, whether the service is in running, paused, or in a stopped state.
- Life cycle and configuration management: Deployment, undeployment, configuration, and status change of Web Services on the platform—for example, changing the state of a Web Service from an "initial" state to a "running" state so that it can accept client requests.
- Performance management and service metering: Throughput, usage, and response time statistics reporting for the platform and for individual Web Services; Audit trailing for Web Services usage.
- High availability: Fault detection in a Web Service during runtime and consequently switching to a failover deployment of the Web Service.
- Mediation: It may provide reliable messaging or even routing of a Web Services request to an appropriate service instance based on its usage characteristics.
- Billing and payment integration: Integration with billing and payment systems based on Web Services usage statistics.
- Subscription: Subscription-based access to Web Services.
- Security and transaction configuration: Integration with Web Services security and transaction infrastructure for configuring them. The security and transaction implementations may themselves be driven by separate specifications, but we need to have a common way of configuring these functionalities and management implementation is the obvious place to do it.
- Publishing: Automatic rule-based registration of Web Services to directories, as in a UDDI registry.
- Orchestration: Dynamic composition of Web Services to create Web Service workflows exposed as new or composite Web Services.
- Integrated systems management: Relevant Operating System and hardware performance statistics integrated in a common console for display.
- SLA and policy systems integration: Integration with SLA5 (Service Level Agreement) and policy management systems. In this case, management data is used to derive the actual values of SLA and policy parameters that can be used to compare it with agreed-upon SLAs and pre-defined policies. This enables monitoring and enforcement of SLAs and policies.
- Versioning: Versioning of server components that are part of the Web Services implementation.
- Notification: Notification of relevant management events via multiple channels.
As identified in the previous section, standards conformance is a desirable aspect of a Web Services management infrastructure. At this point, let us concretely identify the data models and components that would comprise a typical web service management infrastructure and attempt to "standardize" them to arrive at a common architecture.
The management operations to be defined would include those related to deployment, usage characteristics, status reporting, and other advanced management functionality. These data models will ideally be standardized and accepted across vendors. Therefore, it is proposed here to accept CIM as the data model for the Web Services management infrastructure. Another factor that favors the adoption of CIM is that it is already a widely accepted standard across the industry for various management functions and is governed by a reputable independent body. For more information on CIM, refer to the DMTF Web site (www.dmtf.org).
Page 2 of 3