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:
Applications that consume Web services can be aligned to business goals by:
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:
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:
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:
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.