Efficient Selection and Monitoring of QoS-aware Web services with the WS-QoS Framework

Efficient Selection and Monitoring of QoS-aware Web services with the WS-QoS Framework M. Tian, A. Gramm, H. Ritter, J. Schiller Freie Universität Berlin, Institut für Informatik Takustr. 9, D-14195 Berlin, Germany {tian, gramm, hritter, schiller}@inf.fu-berlin.de AbstractWhile the concept of UDDI supports the automatic discovery of services implementing a common public tModel interface, there have been only few attempts to find a standardized form to describe the quality of service (QoS) properties of Web services. We introduce our approach “Web service QoS (WSQoS)” that enables an efficient, dynamic, and QoS-aware selection and monitoring of Web services. The prototype of our approach is implemented with the .NET technology, including the following components: a WSQoS Editor for the specification of QoS properties, a WSQoS Requirement Manager for retrieving QoS requirements specified by client applications, a Web service broker for an efficient and QoS-aware selection of Web service offers, and a WS-QoS Monitor for checking the compliance of the service offers. to find an optimal relation between user satisfaction and system utilization. There are sophisticated technologies to actively differentiate between various QoS levels both on the transport level (DiffServ, IPQoS, classes of services in UMTS and ATM, etc.) and on the server level (load balancing, transaction differentiation, HTTP request differentiation, etc.), yet there are no standardized means to describe the desired QoS on the application level. In terms of the Internet model, the Web services can be placed between the application and network layer. To close the gap between the Web Services layer and the underlying QoS-aware transport technologies, we have developed the Web services-QoS architecture (WS-QoS). The main motivations of our work are • designing an architecture that allows both service clients and service providers to specify requests and offers with QoS properties and QoS classes, • enabling an efficient service offer selection in order to accelerate the overall lookup process for the client, • providing a flexible way for service providers to publish and update their service offers with different QoS aspects as well as • mapping the QoS requirements regarding the underlying transport network from the higher (Web service and application) layer onto the actual underlying network technology at runtime in order to achieve an overall QoS support through the different layers in terms of the Internet model. Therefore, we implemented a WS-QoS framework with the following functionalities: • Application developers can state QoS properties associated with Web services by applying an API or using a graphic user interface (GUI) • Requirement Manager for retrieving and updating client application QoS requirements • Web service broker for dynamic and efficient service selection • WS-QoS Monitor for checking the compliance of service offers • QoS proxies that map the QoS requirements from the higher layer onto the actual QoS-enabling transport technology at runtime (This point is not described in this paper due to the lack of space. It is introduced in [1]).1. IntroductionWeb Services are becoming more and more popular these days and more and more businesses are planning to build their future solutions on the Web service technology. By now, SOAP and WSDL have become reliable standards in the field of Web service execution. While the concept of UDDI allows for automatic discovery of services implementing a common public tModel interface, there have been only few attempts to find a standardized form to describe the quality of service (QoS) with which services are executed. The need for QoS specifications in Web services is driven by two demands. Clients aim to experience a good service performance, e.g. low waiting time, high reliability, and availability to successfully use the service whenever the need arises. On the other hand, when it comes to e-business, service providers need to formulate QoS-aware offers in order to gain the highest possible profit from their business. Examples are high throughput guarantees and low response time through dynamic capacity allocation, resource allocation, and load balancing in order to serve a high number of clients with assured QoS. Moreover, crucial transactions such as payment should experience prioritized execution realized by transaction differentiation. Service providers will striveThe main contributions of this paper are the WS-QoS architecture that enables QoS-aware service specifications as well as the broker based Web service selection model that enables an efficient QoS-aware service selection. The remainder of this paper is outlined as follows: After discussing some related work, we introduce the WSQoS XML schema, since it is important to understand the main idea of WS-QoS architecture. (A more detailed description of the WS-QoS architecture is given in [1].) In section 4, we introduce the implemented framework including the WS-QoS Editor, the Requirement Manager, the Web service Broker, and the WS-QoS Monitor. We conclude with an outlook of future work.2. Related WorkTo enable standardized QoS specification for Web Services three sophisticated approaches for QoS specification within Service Level Agreement (SLA) for Web Services have been developed simultaneously. They are IBM’s Web Service Level Agreement (WSLA) framework [2], HP’s Open View Internet Services [3], and the Web service Offering Language [4] developed at Carleton University in Canada. IBM’s WSLA framework was designed to enable the specification and monitoring of QoS-aware Web services by applying an electronic SLA. While the form of a SLA specification is provided by the XML-based WSLA language [5] the aspect of monitoring the compliance with an associated SLA is implemented in the SLA Compliance Monitor which is part of IBM’s Web Services Toolkit [6]. HP’s Open View Internet Services product enables a business to manage services with respect to a SLA with the emphasis on instant reporting when SLA violations occur. They describe a theoretic Web Services QoS parameter specification model and introduce a Web Service SLA in the form of the XML based Web Service Management Language (WSML) [7]. Automated SLA compliance monitoring has been realized with the Business Management Platform Agent. Furthermore, QoS-aware service choice is achieved through dynamic service ranking according to the different effects that the SLAs in question will have on a composite business process, which are simulated in HP’s Business Process Simulation Environment on the basis of Service Level Information (SLI) provided by service providers. While both WSLA and WSML foster a concept of individually negotiated customized SLAs, a research group from the Carleton University in Canada has developed the notion of providing various classes of service for one and the same functional service specification. The classes of service differ in QoS level and management efforts provided as well as related prices. Distinct service offerings are formally described in the XML-based Web Service Offerings Language (WSOL).Distinguishing between different service levels will influence the strategies to which a business designs its business processes with the usage of Web Services. With this in mind, it is not surprising, that features related to QoS such as security, message reliability and transactional QoS are also issues in business process management (BPM) standards. So far, the most influential standards have been IBM’s Web Services Flow Language [8] and Microsoft’s XLANG [9]. As the most recent development the Business Process Execution Language for Web Services (BPEL4WS) [10] is designed to realize a convergence of the XLANG and WSFL to endorse further standardization with “a common model shared by leading organizations”. High level QoS support might also be addressed during the work on the WS-Integration specifications. Our approach supports not only the specification of various QoS aspects including server performance, network performance, security, transaction, and their dynamic matching at runtime, but also the mapping of QoS requirements regarding network performance onto the actual transport technology at runtime. We call it cross layer communication. The communication between different layers ensures an efficient utilization of the underlying resources as well as a better support of application-dependent requirements.3. The WS-QoS XML SchemaIn this section, we introduce the Web services QoS (WSQoS) approach based on our WS-QoS XML schema. The implementation of the proposed WS-QoS architecture is based on that XML schema.Figure 1. Different kinds of WS-QoS documents As Figure 1 shows, there are three different kinds of WS-QoS XML documents: The WSQoSRequirementDefinition element specifies client QoS requirements. These are minimal requirements which must not be violated by underperformance. The WSQoSOfferDefinition element contains one or more specifications of QoS offers that a service provider is willing to deliver at a price related to a certain QoS level. Both WSQoSRequirementDefinition and WSQoSOfferDefinition are of the type tQoSDefinition, which is introduced in section 3.3. Each of the WSQoSOfferDefinition and WSQoSRequirementDefinition elements contain one or more qosInfo elements (section3.1) that hold information on different aspects of QoS properties. Finally, a WSQoSOntology element holds definitions of custom QoS parameters and protocol references.3.1. QoSInfoA QoSInfo element holds information on the level of QoS regarding the server performance, transport QoS support and protocols required for providing security and transaction support. We have predefined the following QoS aspects with different parameters (Figure 2): serverQoSMetrics, transportQoSPriorities, securityAndTransaction, and extensibilityElement. In a serverQoSMetrics element, values for the standard parameters processing time, requests per second, reliability and availability can be set. Moreover, custom server QoS metrics can be declared in a customMetric element as a child node of the serverQoSMetrics element. Absolute values are set for the parameters of the serverQoSMetrics element.metrics, custom transport QoS priorities can be declared in a customPriority element added to the transportQoSPriorities element. Security and transaction management for Web Services are realized by a variety of protocols. Most of them already have sophisticated mechanisms of negotiating key and session information. Therefore, security and transaction support at this level is restricted to listing protocols needed for a successful service execution. The securityAndTransaction element can hold several protocol elements, each referencing a specific protocol.3.2. WS-QoS OntologyCustom metrics, priority, and protocol support statements all have an attribute ontology, which references a file containing a WS-QoS Ontology (Figure 3) where the referenced types are defined respectively. By using the combination of the ontology’s URL and the parameter name, a reference is unique. A custom transport QoS priority is defined by a distinct name and a human readable definition of what metric the priority refers to in a priorityDefinition element.Figure 3. Structure of a WS-QoSOntology element A custom server QoS metric defined in a metricDefinition element also has a name and a human readable description of what is measured, but it also includes information on the standardized unit of the measurement and the scope of service invocations the metric is aggregated on, that is, whether the value is valid for the (WSDL) port on which the service is invoked, the whole service or even all services of the provider. Furthermore, it has to be stated whether the value is valid for all service executions or for executions requested by the user only. Finally, the direction of how values are to be compared is declared, which is essential for an automated check of whether an offer fulfills a set of requirements. Accordingly, in a protocolDefinition element, a protocol is defined by its name, a human readable description of the purposes of the protocol, the URL of an overview document, and the protocol specification if available.Figure 2. Structure of a qosInfo element In most cases, neither the client nor the service provider knows over what kind of network technology the data will be exchanged. Therefore, it does not seem appropriate to declare explicit values of the transportQoSPriorities element. Thus, we have decided to declare transport QoS priorities, which are to be interpreted by a special component (the WS-QoS proxy), located between the Web service layer and network layer. This component maps the priority-based QoS requirements from the higher layer onto the specific metrics of the actual transport technology at runtime. In a transportQoSPriorities element, priorities can be declared for the four standard transport parameters delay, jitter, throughput, and packet loss rate. Like with the server QoS3.3. QoS DefinitionAn element of the type tQoSDefinition holds one or more QoSInfo elements plus the specification of the contract and the management support and a price. The default QoS properties of a service are defined in the defaultQoSInfo element. But one can also define QoS properties in the operationQoSInfo element which is assigned to specific operations of a service. That means operationQoSInfo overwrites the values defined in defaultQoSInfo. Both the defaultQoSInfo and operationQoSInfo elements are of the type tQoSInfo as explained above. The contractAndMonitoring node can hold references to protocols needed for service management and/or QoS monitoring and entries of third parties that one side would be willing to trust. Finally, the price element relates the specified QoS level to the cost of service usage. Elements of the type tQoSDefinition are either instantiated as a WSQoSRequirementDefinition element expressing a client’s QoS requirements or as a WSQoSOfferDefinition (Figure 4) representing a minimal QoS level a service provider guarantees to supply. The WSQoSOfferDefinition element is extended by an attribute expires which denotes a point in time until which the offer will be valid.• • • •The WS-QoS Editor allows the editing of the QoS parameters through a GUI. The Requirement Manager is responsible for retrieving clients’ requirements. Web service brokers are responsible for the QoSaware service selection. WS-QoS Monitors are used for checking the compliance of offers.4.1. A scenario for QoS-aware service selection From the client point of view, a client application can use one or more types (tModel) of Web Services. The interfaces (WSDL files) of the Web services are known at implementation time. A proxy class (in the context of the Microsoft Visual also known as a Web Reference) is generated from the tModel’s WSDL description for each service type. Static WS-QoS custom attributes or import attributes referencing dynamic requirements in a WS-QoS XML file can now be assigned to the newly created proxy class and its methods (known as web methods in Visual ). Finally, the proxy class is handed over to an instance of the WS-QoS Requirement Manager, which will retrieve the attributes through the reflection technique and thus holds a representation of the current client requirements. One can also use the Requirement Manager to adjust the QoS requirements at runtime without recompiling any code. A possible scenario for a QoS aware dynamic service selection is depicted in Figure 5. On initialization, the client application creates an instance of a WS-QoS Requirement Manager and a WS-QoS Broker (WSB) each. Before service invocation, the client application will request its current QoS requirements from the requirement manager and then inquire the WSB for the most appropriate offer available that fulfills the requirements. The WSB selects the most appropriate offer on behalf of the client from the WSB’s local database. (Note we assume in this case that the WSB has already a local cache of the services the client is asking for. Therefore, the WSB needs not contact the UDDI and the service providers for searching the required service. This model ensures a fast response time.) Once the client gets the required offer from the WSB, the client will invoke the service with the desired QoS properties. The QoS properties are transmitted in the SOAP headers to the service provider that can treat the request based on the QoS properties. For example, it could set the thread priority or, as a load balancer, forward it to one of various possible application servers. Yet, the information is not only intended for the Web service provider: A WSQoS proxy is able to interprete the desired transport QoS priorities and mark the outgoing packets accordingly so that the higher layer applications can take advantages of the QoS support that the underlying QoS-aware transportFigure 4. Structure of a WSQoSOfferDefinition element Each WSDL file contains a reference to a file defining WSQoSOfferDefinition, allowing the dynamic adjustment of offers without changing the WSDL file. Furthermore, an offer could be referenced from multiple WSDL files and thus be reused for different services.4. The WS-QoS ImplementationIn the last section, we have introduced our WS-QoS specification based on our XML schema. In this section, we describe our implementation based on the WS-QoS specification. We introduce the following functionalities: • C# and ASP .NET application developers can define WS-QoS requirements for both client applications and Web Services offers.technologies provide. Furthermore, the information in the SOAP headers can be used to perform encryption or digital signatures.Requirement Manager Client Application Service Broker Service update offers get current offers update offers get current requirements update requirements get cheapest offer (requirements) update selected offer invoke (selected offer) respond check offers against requirements update requirementsFigure 5. A QoS-aware service selection scenario4.2. Custom attributes representing WS-QoS elementsWS-QoS elements can be declared with static custom attributes which are assigned to a service proxy class generated from a WSDL file. QoS elements for specific operations of a service can be assigned to the corresponding Web method. All WS-QoS attributes inherit the abstract class WSQoSAttribute which provides a basic infrastructure for managing the WS-QoS information. In a concrete class the methods getInnerXML() has to be overridden in order to provide an XML representation of the attribute. The method updateProperties(XMLElement) has to be overridden as well in order to create attributes from an XML source. According to the WS-QoS XML schema, the WS-QoS API provides the following custom attributes: • ServerQoSMetricsAttribute and CustomServerQoSMetricAttribute, • TransportQoSPrioritiesAttribute and CustomTransportQoSPriorityAttribute, • SecurityAndTransactionAttribute and ProtocolSupportAttribute, • ContractAndMonitoringAttribute and ThirdPartyAttribute, • PriceAttribute. Furthermore, instances of the classes DefaultQoSInfo and OperationQoSInfo (both inheriting the class QoSInfo) and a QoSRequirements object (which is derived from the class QoSDefinition) are created to hold the attributes retrieved from the proxy class. Apart from holding the values for certain WS-QoS elements, these objects implement the functionality deciding whether one object provides an equal or better QoS level. Their function Includes() is called from the Web service broker (WSB) when testing an offer against a client requirement definition.While the values of most WS-QoS elements can be compared in a simple way, the custom attribute PriceAttribute implements a function IsCheaper() which calls a currency converter object in case that two price statements are declared with distinct currencies. The WSQoS API defines the abstract class CurrencyConverter which holds a static property ActiveCurrencyConverter. This property has to be set to an instance of a class implementing this abstract class before the WSB can make use of the currency converter. The package WSQoSUtil provides the class WebServiceXCurrencyConverter which uses a Web Service from the service provider [12] to obtain current exchange rates. Furthermore, the import attribute is defined to reference XML WS-QoS files containing further requirements, which can be changed dynamically at runtime. When an import attribute is initiated, the imported file is read and a corresponding QoS definition object is built using the attribute’s getInnerXML() method. Then a thread is initiated to perform regular checks on whether (the content of) the imported file has been changed. If so, the requirement manager is informed and the overall requirement object is rebuilt using the updated representation of the dynamic attributes.clickFigure 6. Defining custom QoS properties4.3. WS-QoS EditorThe WS-QoS Editor allows both the service client and service provider to easily edit their QoS requirements or offers, respectively. They need not know the details of the WS-QoS XML schema or any programming skill. One or more XML-based .wsqos files are generated automatically. In case of a service offer, one or more references of the .wsqos files are added manually into the (normally automatically generated) WSDL file of the service. In case of a service request, the Web servicesQoS Requirement Manager will retrieve the values defined in the .wsqos file.Figure 6 shows how a user defines custom QoS properties.4.4. WS-QoS Requirement ManagerOn initialization, the WS-QoS Requirement Manager obtains a reference of the service proxy class to which either requirement attributes have been assigned or a reference to a .wsqos file is given. The Requirement Manager retrieves the QoS attributes either from the proxy class or from the file. It then collects all import attributes, builds WS-QoS definition objects and sets their parent property to receive update messages in case that a .wsqos file has been changed. Finally, the newly built WS-QoS definition objects are added to those retrieved from the static attributes.4.5. WS-QoS BrokerThe WS-QoS Broker (WSB) holds up-to-date information on offers currently available for a group of services which have been requested recently. Offers are grouped by the interface (tModel) that the services providing them implement. The first time a Web service for a certain interface is requested, one or more UDDI registries associated with the WSB are inquired. The WSDL files for these services are then checked for WSQoS extensions and available offers are built. From then on this newly created offer list is consulted in order to find the best match for clients and their requirements, allowing an accelerated lookup process. To keep offer lists up-to-date, the WSB inquires the UDDI periodically regularly in order to check for new offers. Once an offer expires, it is deleted from the WSB’s local cache. If the validity of the offer is extended, it will be re-detected during the next check.test offers against client requirementsa part of the request. In the order of their price, the WSB then tests the available offers whether they fulfill the client’s requirements. The first compliant offer is returned to the client. It is worth noting that one can implement her own strategy for defining the QoS parameters and the selection of the appropriate services. We just give here a simple idea of how the selection could be done. There are two implementations of the WSB. One is a local object running within the application. This ensures a good performance of the service selection and detailed information on available offers, as needed for the WSQoS Monitor described below. The other implementation uses a remote Web Service to obtain the access point of the most appropriate service. This version is mainly intended as a light process for multiple client applications that use a single private WSB that runs as a Web service within their network domain. The WSB could well be used by any other WS-QoS compliant implementation. Figure 7 depicts the participating roles which are service providers, clients, UDDI registries, and the WSB and the interactions among them. Note that there are no service brokers in the standard Web service model [2]. We assume that in most cases service brokers are requested for services implementing interfaces that have been requested before. Therefore, service offers are normally analyzed in advance and testing against client requirements can be performed immediately on receiving a request. Figure 7 depicts the interactions between the roles in case the WSB does not yet have any information about a required service: Note that the WSB in step 7 tests the offers (step 6) against clients’ QoS requirements sent in step 2.4.6. WS-QoS MonitorWe have developed the WS-QoS Monitor which displays all available offers and the current client requirements, making it possible to check the compliance of offers. If no appropriate offer can be found, the overview of possible offers will help the user to evaluate what requirements might be inappropriate and could make the adjustments needed in order to make their application work again. Moreover, the WS-QoS Requirement Manager can be configured to log current requirements. Once this file is registered in the monitor, requirements can be viewed in the requirement watch window or directly in the offer window of the GUI. Finally, the package WS-QoS Util provides a SOAP extension attribute which can be assigned to the proxy’s web methods. The SOAP extension will log WS-QoS SOAP headers for all service requests and responses. One can register this file in the monitor as well use it to survey WS-QoS SOAP headers in the SOAP header watch window of the GUI. Figure 8 shows the main window with the two watch windows inUDDI Registry3request servicesinterface keyService Broker8 get best service 274service service service serviceget servicesinfo1 publishinterface keyrequest serviceinterface key QoS requirementsrequest service description 5 6get service descriptionoffers in WSDLbest offer/ serviceService Provider9 invoke serviceWS-QoS SOAP headerClient ApplicationFigure 7. Interaction between the four participating roles When a client application inquires the WSB for the cheapest available offer, it sends its QoS requirements asthe lower right corner and a QoS-aware client application to the upper right.mobile devices is increasing rapidly. It is well known that mobile devices are resource constrained. They do not have as much CPU power, memory, hard disk, bandwidth, and so on as desktop computers. Therefore, it is useful to analyze the behavior of mobile Web services in order to improve performance and Quality of Service support for this increasing group of users.6. References[1] M. Tian, A. Gramm, T. Naumowicz, H. Ritter, J. Schiller. "A Concept for QoS Integration in Web Services", 1st Web Services Quality Workshop (WQW 2003), Rome, Dec. 2003 [2] A. Dan, A. R. Franck, A. Keller, R. King, H. Ludwig. (IBM) Web Service Level Agreement (WSLA) Language Specification, 2002 [3] HP Open View Internet Services [4] V. Tosic, B. Pagurek, K. Patel, B. Esfandiari, W. Ma, "Management Applications of the Web Service Offerings Language (WSOL)", The 15th International Conference on Advanced Information Systems Engineering(CAiSE'03), Velden, Austria, June 2003 [5] A. Keller, H. Ludwig (IBM), “The WSLA Framework: Specifying and Monitoring of Service Level Agreements for Web Services”, IBM research report RC22456, 2002 [6] IBM Web Services Toolkit [7] A. Sahai, V. Machiraju, M. Sayal, L.Jie Jin, F. Casati (HP) Automated SLA Monitoring for Web Services [8] F. Leymann (IBM) Web Services Flow Language (WSFL), May 2001 [9] S.Thatte (Microsoft). XLANG - Web Services for Business Process Design, 2001 [10] IBM, Microsoft, Bea, SAP Business Process Execution Language For Web Services 1.1, May 2003 [11] BPML / BPEL4WS - A Convergence Path toward a Standard BPM Stack, August 2002 [12] Figure 8. WS-QoS Monitor surveying the service selection of a sample client.5. Conclusions and Future WorkThe integration of various QoS aspects is important for the success of the Web service technology. In this paper, we have introduced our WS-QoS approach and its implementation. Based on the WS-QoS XML schema, both Web service offers and requests can be associated with QoS offers and requirements. Our approach allows an efficient and QoS-aware service selection in comparison to the UDDI concepts. Furthermore, the WSQoS Monitor helps users to check the compliance of service offers and to identify inappropriate definitions of QoS requirements. Our ongoing research includes the introduction of weighting factors associated with the different QoS aspects and parameters. We have built a testbed in order to conduct performance measurements of our architecture. We are interested, for example, in the performance of the WSB for selecting the most appropriate service in comparison to the standard lookup model and other approaches introduced in section 2. Another important issue is the support of mobile devices. The current Web service concept is designed for application to application (A2A) communication running on desktop computers or servers. The usage of small and[13]Heather Kreger, IBM Software Group, “Web ServiceConceptual Architecture (WSCA 1.0)”, May 2001。