Web Services Management: A Standards-Based Common Architecture
As enterprises rush to deploy Web Services-based solutions, problems in managing the services may become 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, to an administrator, and to 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 part of this two-article series, we will focus on the expectations from a Web Services management infrastructure. In the second part, we will propose and discuss a common architecture for the same.
The growing prominence of Web Services1 technologies is likely to lead to their adoption by businesses as a preferred application platform. However, to derive consistent business benefits from these technologies, Web Services applications and platforms, among other characteristics, need to
- Provide guaranteed quality of service.
- Be easily usable by service administrators in a production deployment.
The above requirements mandate that the Web Services products be "managed" well—in terms of monitoring, control, and co-ordination. Only in a well-managed Web Services ecosystem can QoS2 (Quality of Service) parameters be measured, manipulated, and enforced.
Gartner has highlighted the need for Web Services management solutions: "As the hype about Web Services grows within the IT industry, real solutions for managing cooperating Web Services must emerge, or failures will ensue."
Notably, there is an emergence of new application architectures based on Web Services technologies, as opposed to earlier monolithic or centralized architectures. Therefore, IT management technologies, too, have to evolve to keep up with the new requirements these architectures impose. Another diversity in the Web Services world is the parallel growth of J2EE (JavaTM 2 Enterprise Edition)-based and MicrosoftTM .NET-based deployments. A management strategy must encompass these two major platforms, as well as any upcoming platforms for Web Services. Also, to reduce the costs of its adoption, a management infrastructure must offer simplicity of use for administrators and, preferably, integration with existing management standards and products.
In the following discussion, we will analyze Web Services management requirements and, based on that, propose a platform-agnostic, common architecture for a Web Services management infrastructure compliant with suitable and popular standards.
We will focus on the expectations from a Web Services management infrastructure in this article and in the second part we will propose and discuss a common architecture for the same.
A Web Services management infrastructure would be typically deployed and operated by the "Web Services administrators." The administrators, normally part of an IT organization, would manage different sets of Web Services components depending upon the hosting configuration. Therefore, the requirements on what a Web Services management infrastructure must comprise will become clearer if we first take a look at various Web Services hosting paradigms and responsibilities of administrators in each of them.
Web Services hosting scenarios and administrator responsibilities
ASP3 (Application Service Provider)-hosted Web Services
In this scenario, an independent ASP is used by a Web Services provider to host Web Services of, for example, a small business. A Web Services provider in this case is a company that develops and deploys the Web Services for the business. The service administrator manages the Web Services development environment at its end as well as the deployment environment at the ASP end. The ASP thus has to provide a management access to a part of its environment to the administrator (See figure 1(a)).
Service Provider hosted Web Services
The Web Services provider itself hosts the Web Services here. This is a simplistic set up where the service administrator manages services deployed within the purview of the service provider's environment (See figure 1(b)).
Mediated Web Services
This is another realistic configuration where Web Services are listed at a "service broker" intermediary but hosted at the service provider's end. The service administrator in this case manages the service provider's hosting environment as well as a part of the broker's environment. An example of an intermediary is a portal that lists Web Services in a particular domain and lets users search and access them (See figure 1(c)).
Web Services client management
A variation of the preceding scenarios is the case where a portion of the Web Services client also needs to be managed remotely by the service administrator. (In this case, a Web Service may be running at the client end.) An example of a client that needs to be managed is the TV set-top box that can be manipulated remotely to let it decode only a limited number of channels (See Figure 1(d)).
Outsourced Web Services management
Another scenario, which takes the concept of services to the next level, is where some service providers offer Web Services management itself as a service and Web Services providers outsource management to these service providers. Thus, in this case, third-party providers manage a Web Services provider's infrastructure and services.
Web Services Management: Common Administration Aspects
From the previous discussion, the following common points can be derived about general administrative responsibilities in the various Web Services hosting scenarios:
- A Web Services administrator needs to manage a Web Services platform as well as the Web Services that are deployed on the platform.
- The administrator also needs to manage the systems and the network in a limited way, considering that some of the service QoS parameters are dependent on them.
- The management responsibilities may span remote sites—possibly across the Internet.
Figure 1: Web Services hosting scenarios