Modeling the Aspects of Quality of Service in Web Services and ...

More documents

Recommendations

Info

to determine if the quality of a service has been changed since the previous encounter of the two parties. 2. Significance QoS can be used as the means of measuring applicability when searching for a service, and after the usage of the service for measuring the efficacy of the SP. The notion of QoS applies to an end-to-end basis, so QoS in the context of WS becomes an abstract term by which the quality as perceived by an SC can be measured. The quality perceived by a number of SCs may vary greatly for the same service provided by a single SP. In this research, the term QoS is the perceived quality by an SC that is exclusive of all the other SCs that are using the same service. Thus, it becomes important, as the number of SPs increase, the ability to determine with some level of certainty the quality of a service in order to distinguish between the various SPs. There are two ways of measuring quality: • Determine attributes before • Calculate quality after the usage Since we are, for the purpose of this research, not interested in self-improving services (intelligent agents, self modifying code, etc), the latter of the two options is not of value. We would like to be able to predetermine as much as we can about a service before we start using it. Based on the current working standards, there is no way for an SC to determine if a service is better than another service offered. For the situation where services are deployed over the Internet and an SC must pay-perusage, it is crucial to find as much as possible about a service before an SC starts using a service. 3. Approach and Methodology This paper will show the benefits of adding the notion of QoS to WS and SOA at the service discovery phase. We will propose an extension to the current protocols through an elaborated example in which a number of SPs provide search engine services with each one having a different search algorithm. It will start by integrating the basic principles of QoS outlined in [10] into WS. These principles are as follows: • Principle of Integration • Principle of Separation • Principle of Transparency • Principle of Asynchronous Resource Management • Principle of Performance Each of these principles will be depicted as they apply to the concept of WS and SOA. A brief description of the components that make up WS, mainly UDDI, WSDL, WSEL and SOAP, will be given along with the role that each component plays in a SOA. An example application that utilizes the SOA will be shown to clarify the changes that need to be made to current protocols. This research mainly focuses on the role that QoS plays in the service discovery phase – a role that is played by the proposed UDDI standard. Therefore, a more detailed description of the UDDI will be given along with a list of proposed changes to the current proposed standard to allow it to take advantage of QoS. These changes even thought very minor, play an important role in the discovery and usage of a service. Our example consists of a series of SPs that provide a document search service to the SCs in an enterprise. The SPs receive queries from the various SCs and search a database for matches – Boolean or otherwise. Each SP employs a different search algorithm and depending on the SCs needs, a different SP is used. The SCs, through the service discovery process, will determine which SP will be able to handle their request. In addition to the basic search criteria, which we will call Functional Attributes (FA), there can be other search criteria used to determine the applicability of the SP. Quality Attributes (QA) will be used in conjunction with the FAs to determine the QoS of an SP. During the service discovery process, the QAs are used to map the applicability of each SP’s capabilities to the SC’s request and are assigns a value. The combination of all the values assigned via these QAs will be called the QoS Value (QV) throughout this paper. We aim to model the discovery dialog that takes place before a service is acquired in order to predetermine the QV based on the QAs that are of significant value to an SC. In the current working standard, it is mainly the FAs that are taken into consideration. Examples of FAs are the service name and contact phone number. In [1] examples of what it called non-functional properties, or what is called QA in this research, are given: • Availability: the availability of service for use • Accessibility: the probability degree of success of accessing the service • Integrity: available mechanisms for ensuring data integrity considered – rolling back in case of failure, for example • Performance: the performance of the service using some available metric(s) • Reliability: the reliability of the service using some available metric(s)
• Regulatory: Regulatory and legal compliance • Security: the security of the service in terms of communication with the SC It is important to note that some of the QAs are very difficult to quantify: some heuristic needs to be considered to determine some of these values. Past history can be used as an estimate for some the QAs that are difficult to quantify. For purposes of this research, it is assumed that these estimations have some basis and are kept up to date by the SP. In addition to the dynamic flexibility of SOA, we also aim to show that the notion of QoS also benefits reliability, scalability and predictability of a distributed architecture. 4. QoS Principles As mentioned in the previous section, the principles of QoS [10] need first be applied to the concept of SOA and WS to ensure the integrity of our model. Some of these principles are as follows: • Principle of Integration • Principle of Separation • Principle of Transparency • Principle of Asynchronous Resource Management • Principle of Performance The Principle of Integration states that QoS must be configurable, predictable and maintainable over all architectural layers to meet the end-to-end QoS [9]. The focus of this paper is on the predictability factor of QoS as it applies to WS during the service discovery phase initiated by the SC. The ability to configure and maintain QoS will be secondary, since they are for the most part left for the implementer of the SC and the SP. The Principle of Separation states that content transfer, control and management are functionally distinct architectural activities [11]. In SOA, each of these activities, are accomplished separately by virtue of how the UDDI protocol finds and manages services. The Principle of Transparency states the application should be shielded from the underlying QoS management and maintenance. The Principle of Asynchronous Resource Management models the control and management mechanisms of QoS [11]. The Performance Principle includes a wide variety of guidelines from [12] [13] and [14]. Some aspects of these principles do not apply to WS and SOA as it stands today. It is important to mention them to ensure that the changes proposed will not negatively affect these principles. 5. Web Services Technologies The four main protocols proposed for WS and their purpose and functionalities are explained in this section. However, it is beyond the scope of this document to explain each protocol in detail. The reader is referred to [7] for UDDI, [8] for WSDL, [2] and [3] for WSEL and to [5] for SOAP. 5.1 UDDI The Universal Description, Discovery, and Integration is used for the discovery of services. It is a specification for publishing and finding businesses and services provided by those businesses. 5.2 WSDL The Web Services Description Language is used to describe the interface of the service, its available functions and their signatures. 5.3 WSEL The Web Services Endpoint Language is used to model non-functional characteristics of services. This protocol is currently being developed by IBM. 5.4 SOAP The Simple Object Access Protocol is an XMLbased protocol for exchanging information between applications or services. 6. Search Engine Service Without the use of QoS, only the FAs of a search can be verified. Figure 1 shows how that task is accomplished today. The services publish their service description and other information needed to access the service to the directory service. The User Application or the SC search the directory, implemented in UDDI, for a specific service. For the purposes of this paper, we will use a generic Search Engine Service (SES) to demonstrate our proposed extension to UDDI. The SES takes queries from the SC and searches a backend database or other available databases for results request it by the SC. For the simple case as depicted in Figure 1, the current working standard for UDDI will suffice. There are three SES’s, each one offering different FAs; each one is using a different algorithm to do the search. In this scenario, where FAs can be used to distinguish between the services, a simple search by service type will unveil the desired service. It is unpredictable, however, if there are many SPs offering services with the same FA. The
Page 1: Modeling the Aspects of Quality of
Page 5 and 6: We assume in this case that the bus
Page 7 and 8: Type Attribute Attribute Name Examp

Modeling the Aspects of Quality of Service in Web Services and ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?