Introduction
With the boom in distributed computing, the Internet world is heading towards Services Oriented Technologies. Web Services have become the buzzword of today. Web Services offer easy and standardized communication for loosely coupled and dynamically discovered software components over the Internet. Enterprises have started experimenting with Web Services at their corporate intranets before actually going live to their customers over the Web.
Being distributed and dynamic in nature, Web Services need to be managed with care.
Web Services Management is what we are going to talk about now. This article analyses the requirements of Web Services Management (referred to as WSM in this article) Platform. To address the functionalities required in WSM, we’ll introduce the basic components of WSM. This article, then, aims to develop a basic understanding of the core components of the Web Services Management Platform.
In the forthcoming articles, we will discuss each one of the components of WSM in detail and propose implementation architectures for them.
What Are Web Services?
Even if the technologies such as CORBA and COM introduced the services-oriented distributed concepts, they could never become the universal choice of enterprises and developers. In search of standardization and simplicity, e-business technologists and customers looked forward for a loosely coupled and dynamically discovered services technology, which is known as Web Services. These services are software components developed by their vendors to solve some business problems. These services can reside on different systems and can be implemented by vastly different technologies, but they are packaged and transported using standard Web protocols, such as XML and HTTP, thus making them easily accessible by any user on the Web. Web Services Technology has become a key to the Service Oriented Internet World in a very short time period because it promises the interaction of unknown and unrelated applications on the Internet in a more standardized and simpler way than any other approach ever claimed.
Why Manage Web Services?
After understanding the nature of Web Services, we can see their deployment scenarios where the following four players have vital roles to play:
- Web Services Provider (WSP)—This is the entity (for example, a business organization) that designs and develops Web Services.
- Web Services Infrastructure Provider (WSIP)—This entity provides the infrastructure services to deploy Web Services at its premises.
- Web Services Broker (WSB)—Broker has the information of Web Services hosted by WSIP or WSP in the Web Services registries.
- Web Services Client (WSC)—Clients are actual consumers (or, end-users or applications) of Web Services.
Web Services can be deployed in various fashions and on different platforms. This strongly urges a need to manage them in a centralized sphere of control depicted by Figure 1:
Figure 1: Web Services Management—Control Sphere
Note: The direction of the arrows shown in Figure 1 is the direction of the flow of requests initiated by Web Service Clients. Consider an example of this flow: WSC requests WSB to provide the information of a registered Web Service. After getting the response, WSC invokes the Web Service provided by WSP and hosted by WSIP. This flow depends on the design and deployment of Web Services in a business scenario.
The previously-discussed four players (shown in Figure 1) may or may not play a role in the control sphere. Their participation depends upon the Web Services deployment configuration/fashion. This control sphere is also referred as the heart of the Web Services Management Platform (referred to as WSMP hereafter).
Digging into the complexity of business in the present world, there are many development and deployment scenarios possible for Web Services. These scenarios, when needed to interoperate, create more complicated systems. If these systems are not operated carefully, they may hinder the advantages of Web Services. To have control over the above-mentioned complexity of the heart of WSMP, we must have a wrapper of management services over it. This wrapper is responsible for managing Web Services and the four players, which are operating in the heart of WSMP.
The primary goal of enterprises that are currently using Web Services is to derive a business sense out of this technology and drive their strategies based on that. This can only be done when they have proper control over Web Services offered to their customers. This control can be visualized by some infrastructure services in the above-mentioned Control Sphere. There are many core requirements for Web Services to work in a commercialized world where they can help enterprises get returns for their investments.
When we translate the above-discussed needs into the components of the wrapper over the heart of WSMP, we see these core modules:
- Access Mechanism (Authentication and Authorization)
- Web Services Provisioning (Subscription, SLA, and License (Contract) Management, Monitoring, Metering, and Billing)
- Secure Communications
- Service Virtualization and Workflow Management, and so forth
Web Services Management Sphere
Having discussed the need of various infrastructure components of the WSM Sphere, we will now see that our Sphere looks like this:
Figure 2: Web Services Management Sphere—Core Infrastructure Components
Note: The components shown in the WSM sphere are the core functionality modules identified. Different vendors of the WSM platform may identify more advanced pieces in their WSM sphere.
Now, let us briefly discuss each one of the infrastructure components.
Tools
These tools aim to assist:
- Web Services Providers develop their Web Services.
- Web Services Infrastructure Providers deploy the Web Services.
- Web Services Brokers provide Web Services information.
- Web Services Clients invoke Web Services.
Access Control
The WSM infrastructure should be able to authenticate and authorize Web Services Clients. When a client logs in, a session is created and maintained until he/she logs out of the system. Sessions are used in various other components of WSM as well.
Logging
Web Services requests, responses, client session-related information, various events, and so forth should be logged. These logs are used for various vital operations, such as Services Provisioning, Monitoring, Performance Evaluations, Business Trend Analysis, and so on.
Monitoring
Web Services monitoring is essential as a part of management functionalities. Web Services Administrators should be able to monitor various events of all the deployed Web Services. This helps the administrators analyze business trends and manage Web Services.
Service Provisioning
Web Services Provisioning is responsible for defining the system behavior in terms of its technical and business functionalities.
For example, Web Services Clients should subscribe to Web Services. Clients are authenticated and authorized based on their subscription account before they access Web Services. Then, they are billed based on their usage of the system.
Here are the building blocks of the Web Service Provisioning System:
Subscription Engine
We can look into the subscription engine from these two perspectives:
- Administrator—This is the person responsible for defining various business terms and rules for the deployed Web Services. He/She can group different Web Services under Catalogs and set rules for the same. This way, all the Web Services having similar kinds of business functionalities can have the same sets of rules. The administrator should be able to manage various users (administrators and Web Services clients) and the subscription policies for Web Services.
- Web Services Clients—These are also called the business users of Web Services. Clients should be able to enroll themselves and then browse the directory of Web Services whose access has been given by the administrator. Clients, then, can apply for the subscription of listed Web Services.
Contract Management
Contracts are defined for linking the Web Services Clients to the terms of service (these terms include billing and rating packages). This contract is associated with each subscription of Web Services Clients. When the clients invoke the Web Services, authentication, authorization, and identity systems match the associated contract. Web Services Clients will not have access to invoked Web Services in case of an invalid contract.
In this process, Service Level Agreement (SLA) and Quality of Service (QoS) management applications play their role.
Metering and Billing
Clients will access Web Services based on the contract they have agreed upon when they subscribed to Web Services. To bill the clients, the system should be aware of the statistics of the contract, SLA, and QoS promised to the clients. A metering application gathers this usage and session statistics and the Billing application is responsible for co-relating the above-mentioned two statistics and produces a bill to the clients. Therefore, the Contract Management and Metering application should be treated as inputs to the Billing application.
Life Cycle Management
As the name of this WSM component suggests, it manages various stages of the Web Services life cycle. These stages are development, deployment, registering, and testing. The Life Cycle Manger keeps the information of each one of these stages and presents it to WSM administrator(s). It works in synchronization with WSM Tools, which control and manage various stages of Web Services (discussed under the “Tools” section, above).
Auditing
This WSM component is built on monitoring and logging components. The basic functionality it offers is to produce audit trails enabling the reconstruction and examination of a sequence of events in Web Services context. The Auditor fulfills this function by reliably and securely keeping records of security-related events. Various security event data can be obtained from the logging application. Security events could include authentication events, policy, enforcement decisions, and so forth. The resulting audit trails may be used to detect attacks, confirm compliances with policy, deter abuse, or other purposes.
Mediation
Mediation functionality enables the automated composition or federation of Web Services developed by various Web Services Providers (WSP) via a registry service. This component takes care of runtime dynamic discovery, subsequent binding, and execution of Web Services, from both a technical and business perspective.
Event Management
There are various events defined in the Web Services life cycle; these events can be grouped together in technical as well as business contexts. Event Manager is responsible for keeping stock of these events per Web Services basis. Various rules can also be configured using Event Manager; for example, sending alerts if any event occurs, setting thresholds for events, and so on. All event information should be able to be presented to administrator(s) for further analysis or feeding to other WSM components.
Security
Security Manager offers and guarantees authentication, authorization, privacy, trust, integrity, confidentiality, secure communication channels, federation, delegation, and auditing across a wide variety of Web Services.
The security mechanism enables us to achieve the following goals by a process in which:
- A Web Service can mandate an incoming message proving a set of claims (name, key, permission, capability, and so forth). If a message arrives without having the required claims, the service may ignore or reject the message. We refer to the set of required claims and related information as policy.
- A requester can send messages with proof of the required claims by associating security tokens with the messages. Thus, messages both demand a specific action and prove that their sender has the claim to demand the action.
- When a requester does not have the required claims, the requester or someone on its behalf can try to obtain the necessary claims by contacting other Web Services. These other Web Services, which we refer to as security token services, may in turn require their own set of claims. Security token services broker trust between different trust domains by issuing security tokens.
This mechanism can be developed implemented by using the WS-Security specifications.
Workflow Engine
Workflow is a very prevalent concept in today’s business world and it applies to Web Services as well. As we know, Web Services are software components developed to solve some particular business problem. It makes a lot more sense to design business functionalities by visualizing a flow of more than one Web Service. This flow finally solves a bigger business problem than solved by its constituting Web Services when operated in an isolated manner.
Workflow Manger fulfills the above-mentioned need. It creates, tests, and manages the logical flows of Web Services. Dynamic discovery from registries, Security, and Transactional aspects of workflow are also covered in the engine.
Virtualization
A Virtualization application creates and manages ‘virtual’ endpoints for Web Services. The virtual endpoints can be dynamically associated with ‘real’ endpoints to manage fail-over, provide load balancing, and concurrently manage multiple versions of Web Services.
NOTE: As the readers must have noticed, some functionalities are covered in more than one WSM component. Actually, this is because some of the WSM components (Security, Life Cycle Manager, and so forth) have vast scope and their requirements overlap the need of relatively small WSM components (Auditor, Monitor, Logger, and so on).
Web Services Management Platform vendors should carefully design the WSM components and they may logically combine WSM functionalities into various WSM components.
Summary
This article discussed the requirement and scope of Web Services Management—Control Sphere.
Various WSM components of the Control Sphere are introduced and their functionalities are briefly discussed in this article. Subsequent articles in this WSM series will discuss each of the components in detail.
References
White papers, articles, and news are posted at the following Web sites:
http://www.w3.org/
http://www.webservices.org/
http://www.w3.org/TR/2002/WD-ws-gloss-20021114/
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp
About the Author
Manoj Seth is a senior software engineer at Hewlett-Packard, India. He is a Post Graduate from the Indian Institute of Information Technology, Bangalore.
Manoj has been involved in designing and developing J2EE-based solutions over various platforms in the domains of Financial/Banking and Middleware for more than two years. He has good exposure to Web Services and their emerging standards in development/deployment and management space. He can be contacted at manojseth_2000@yahoo.com.
Acknowledgements
The author would like to acknowledge the contributions of Pankaj Kothari at Hewlett-Packard, India for his insightful comments and reviews.
