Web Services Management

As the number of Web services increases and starts to invade the enterprise software environment, a management layer becomes increasingly important. Currently the demand for Web services management products is not very high since most enterprise Web service initiatives are still in their infancy and involve just a handful of services. As more of these initiatives are migrated from pilot projects to deployment rollouts and as the number of consumed Web services increases, Web services management will quickly become a critical capability.

In this section, we briefly explore the concepts and issues underlying Web services management. We discuss what Web services management is, why it is important, and how this technology can be used to build robust and cost-effective enterprise systems. We also discuss the Web Services Distributed Management (WSDM) standard.

The Objectives of Web Services Management

Web services allow individual functional software components to be developed and exposed to other applications and services. This level of fine granularity is leading to an explosion in the number of Web services that are available from different sources and from different vendors. A Web services management platform enables a company to manage individual Web services as business resources that can be manipulated and used to meet business goals. Web services management is not just about monitoring the uptime of software components.

How can Web services management be used to further business goals? Simply put, developing a Web service and making it available for others does not necessarily fulfill any business goal. Neither does building an application that consumes Web services.

Developed Web services can be aligned to business goals by:

• Making the service available as a revenue-generating service that is tied into the company's billing and invoicing system.

• Allowing priority-based access to selected Web services for customers who pay premium prices.

• Reducing duplication of effort and costs by allowing others a view into all available Web services so that the same functionality is not developed again.

Applications that consume Web services can be aligned to business goals by:

• Making available the different vendors that provide the desired Web service functionality.

• Allowing changes to the consumed Web services based on the most competitive pricing or quality.

• Monitoring who within the company is using which services.

• Determining which people or groups should be charged for Web service usage.

• Reporting on the level of service received by applications.

Sometimes architects question the value of adding another architectural layer, instead of just incorporating the required capabilities within the application or service. A few reasons necessitate the Web services management layer. First, the Web services platform is a moving target: new technologies are being added, existing technologies are being changed and some technologies are even being removed all together. The composition of the Web services platform will determine the requirements for services management. Additionally, industry standards for Web services management are under development and are changing. If services management capabilities were to be built into applications themselves, each application would have to be modified and maintained as the Web services management technologies and standards changed. The time and expertise necessary to maintain these applications would be prohibitively expensive. By abstracting out the services management technologies into a distinct architectural layer, we are able to achieve cost-effective application development and maintenance without requiring all application developers to be fluently versed in all services management issues. A distinct management layer also dissuades individual developers or groups from designing and implementing their own management solutions, which may be difficult or expensive to rectify and coordinate with other management solutions.

Web Services Management Modules

The individual modules that comprise and will be required of a Web services management platform will evolve and change over time with the increasing use of Web services. Nonetheless, Figure 11-10 depicts a basic Web services management platform and how this platform fits within a Web services architecture. Different Web services interfaces are available for applications to invoke. Application requests to a Web service interface are routed through the Web services management modules to the actual service implementation. The service implementations can be located on the same machine as the Web services management platform, or they may be remotely located and connected by networks.

Figure 11-10. The use of Web services management within an enterprise Web services environment.

Security. One of the major hallmarks of Web services management is to allow secure and authorized access to Web services. The Security module of the Web services management platform can be thought of as an XML application firewall that keeps unwanted SOAP traffic out but facilitates and records access by authorized users.

Network firewalls do not sufficiently address the needs of secure Web services. For starters, firewalls enforce policies based on analysis at the packet level. An effective Web services firewall will need to apply policies at the message level, not at the individual packet level. Policies and analysis at the SOAP message layer affords additional opportunities for filtering and security that are not available at simply the packet layer.

Since many Web services will be available to both internal consumers (within the enterprise) as well as external, public consumers, the Security module must provide a variety of capabilities:

• Encryption and decryption

• Authentication and authorization

• Single sign-on

• Intrusion detection and filtering

• Non-repudiation

Even within these individual capabilities, the Security module will have to support a number of mechanisms. For example, consider some of the different means of verifying the identity of Web service users: username and password pairs, certificates, and license keys. Although a username-password pair may work well for a small number of corporate partners who are using a service, such an authentication scheme may not work well for a service that is accessible by the public.

Security solutions such as SSL also may fall short. SSL provides security between two servers, but does not adequately address the scenario in which a SOAP message is routed through multiple servers along the way to its final endpoint destination. Authentication information needs to be forwarded to servers, but a standard mechanism for doing so using SOAP messages does not yet exist. If the secure Web server handles authentication and data decryption, the information sent to the endpoint is insecure. Some of these issues will be addressed by solutions such as the Liberty Alliance and Microsoft's Passport.

Monitoring. Once service requests have been identified and approved for access, they must be monitored and recorded for accounting and performance tracking needs. Web services monitoring involves a variety of steps, including:

• Usage and Performance Logging: A set of applications, each with a number of users, will invoke Web services. For each such invocation, a record is kept of each user as well as the performance of the service for that user. Decreased performance by a Web service may trigger alerts notifying the appropriate managers and decision makers. The statistics gathered are important from a reporting perspective, but also have tremendous value in improving a service or application's performance.

• Accounting: Some services will be available for free, while others will be premium services available only through a subscription or a fee. Various service providers will have diverse rates and may be different depending on the user. The accounting capabilities within the monitoring module support a variety of charging, reporting, and dispute reconciliation mechanisms. Since the access fees to Web services will typically be small, the micro-charges and micro-payments will be aggregated together before being inserted into the corporate accounting software.

• Access Control: Once a user has been properly identified and authenticated, access control mechanisms are used to determine whether that user has access to a particular Web service. In some cases, a single Web service may have different implementations and deployments that are available for different users, perhaps based on subscription or pricing levels.

• Performance and Quality of Service Management: Monitoring the performance of Web services will be critical as many enterprises will not rely on third-party service providers without a contractual obligation with respect to a service level. Such service level agreements (SLAs) will be binding on both service providers and service consumers. The performance management capabilities within the monitoring module are important for both service providers and for service consumers. Providers must make sure that their services are delivering the required performance, and must also monitor that their consumers are adhering to their obligations. Similarly, consumers must monitor that their applications are adhering to their SLAs and must also monitor that their service providers are doing the same.

Brokering. Once it has been authenticated and identified, and it has been monitored, recorded, and access control rules have been applied, a service request is ready for brokering. Brokering involves a number of capabilities, including:

• Service Selection and Routing: Hardwiring an application to use a particular Web service reduces the robustness of the application, and also does not allow it to efficiently take advantage of new services. By brokering service requests, a single request can dynamically select the most appropriate service implementation and automatically route the request to that endpoint. This is important not only for changes to a service's endpoint information, but also as new competing services become available. The service selection can be based on quality of service and performance information, or even by analyzing the contents of the message body.

• Request Transformation: Different service implementations may have different interfaces or format needs. In the process of routing a request to a different service implementation, a service request may need to be transformed to meet the requirements of the dynamically selected service implementation.

• Service Invocation: Not all service implementations may support the same version of a communications protocol, or even the same protocol. The exact messaging requirements of a particular service should be abstracted away, so that applications have access to a wide variety of services to use. Whether a service is a SOAP service or a CORBA service makes no difference to the consuming application; the functional capabilities of the service should be the only relevant issue.

We have discussed some of the key features required of a Web services management platform. By abstracting services management into a separate architectural layer, applications and services can be efficiently developed, even as the Web services management technologies and standards evolve and change.

Web Services Distributed Management

Web Services Distributed Management (WSDM) is the name given to a new technical committee formed within the Organization for the Advancement of Structured Information Standards (OASIS) standards body. The objective of the WSDM technical committee is to define an industry standard specification for Web services management. This includes not only defining a model for Web services as manageable resources of an enterprise, but also using Web services technologies to manage distributed resources.

This process is still in its early stages, and the technical committee expects to release the initial specification in January 2004. The latest information about the WSDM specification and the progress of the technical committee can be found at http://www.oasis-open.org.