Web Services deployment in enterprises is in vogue. Web services achieve a high level of interoperability among the participating systems due to their use of standard protocols. Managing Web Services is becoming mandatory because of its widespread adoption in huge enterprises. Web Services are becoming pervasive in enterprise computing, thus lowering the maintenance costs and decreasing the system downtime, which is critical for the success of this technology. In this article, we are going to discuss a reference container, which manages and monitors the Web services.
Web Services Management Requirements
The compelling requirements for Web Services Management (WSM) have prevailed in the industry for quite some time. We will try to address these requirements in our Web Services Container (WSC). The requirements are as follows:
- To monitor the availability of the Web Service
- To load balance the Web Services
- To monitor and if possible control the performance of a Web Service
Typically, Web Services represent a wrapper around the existing EAI applications or legacy systems. To appreciate the concept of a Web Services Container (WSC), product vendors or implementers should understand these basic requirements, which are crucial for any Web Services Management platform.
Web Services Container Architecture
The concept of a Web Services Container is a layer of abstraction that holds the enterprise-wide services, which are exposed as Web Services. This draws a parallel to the J2EE container for managing enterprise beans. It maintains a pool of Web Service Beans that services the requests from the request queues. Figure 1 shows the architecture of a typical Web Services container.
The core components that form the basis for the Web Services Container are:
- Configuration engine
- Security engine
- Service execution engine
- Service Monitoring engine
The configuration engine helps in configuring various parameters such as performance, logging, monitoring, and security of Web Services. Achieving high availability and load balancing of the Web Services are very critical to the success of any Web Service Management platform. This should be made configurable through this engine.
Web Services should be available for consumption only by authorized clients that make secured requests to the service. This provides one level of security to the service being accessed. This can be either achieved through Access Control Lists (ACL) or digital signatures. The security engine helps to configure the security-related parameters for a particular Web Service. The Web Services Security (WS-S) specification is currently a working draft under the OASIS TC.
Service requests are put into service queues. The Worker Thread Manager will allocate threads based on the configuration specified for that particular service.
The Monitoring engine updates the information about the availability of the service with the help of service agents that sit on top of all the applications that are exposed as Web Services. This information is stored in a database. Once the request is made to that particular service, the Service Execution engine will check with the Monitoring engine and will service the requests to the pool of Web Service beans based on its availability.
In case the service is down for maintenance, the requestor will be notified of its unavailability. In order to achieve high availability, one can think of load balancing Web Services. The requested service can have multiple instances running as Web Service beans in the service pool. This can be done through a heartbeat mechanism that happens within the cluster of services that participate in load balancing. Once the service is down in the cluster, any available service could be notified for failover. When a request arrives to the failed service, it will be redirected to a similar service which is alive, thus making the Web Service request processing opaque to the service clients.
Figure 1: Web Service Container Architecture
This article has discussed the need for a container to manage the Web Services. The approach and architecture are to serve as a reference for a typical Web Service Management platform. The extension of the architecture is to standardize various components of the architecture as well as their communication interfaces.
About the Authors
R Venkatavaradan has been working as a Technical Consultant for Hewlett-Packard. He has a Masters Degree from the School of Automation, Indian Institute of Science, Bangalore. He has about 13 years of industry experience. His field of work ranges from signal processing to Web Services, J2EE, Enterprise Application Integration, and so forth. He has extensively worked on Web Service technologies such as WSDL, SOAP, and UDDI, and provided technical consultancy to various projects in the field of mobile, telecom, and EAI, which have been architected based on Web Service concepts. He can be reached at firstname.lastname@example.org.
Arulazi Dhesiaseelan has been working as a Senior Software Engineer for Hewlett-Packard. He has a Master of Computer Applications Degree from the PSG College of Technology, India. He has about three years of industry experience. He was also involved in the UDDI4J project hosted at http://uddi4j.org. He has been working on Web Service-related technologies such as WSDL, UDDI, and SOAP. Currently, he is involved in developing an open service framework for mobile infrastructures. He can be reached at email@example.com.