PROBLEM STATEMENT

Developing a model for measuring the reusability of service by quantifying the quality of service

RELATED PAPERS 1. Abstract

Date of Current Version: 08 April 2010 Quality of Service (QoS) differentiation in WiMAX networks is a critically important part of QoS support that has not been properly addressed in the literature. Radio Resource Management (RRM) techniques such as packet scheduling and admission control have been studied by many research groups, and although they claim to provide QoS differentiation in their schemes, no studies have truly evaluated and measured the QoS differentiations among various service classes. In this study, we propose quantifying QoS differentiation using a new parameter called Fairness, which could measure QoS differentiation among various service classes. By simulation results, we show that Fairness values could provide detailed information about QoS differentiation, where throughput and delay fall short of comparison analysis for QoS support among Real Time (RT) versus Non-RT (NRT) applications.

2. Abstract
Date of Current Version: 01 February 2008 Quality of service (QoS) support in the current Internet is indispensable because of QoSsensitive real-time applications such as voice-over-IP, IP-TV, video conferencing, online gaining etc. Since the introduction of the differentiated services (Diff-Serv) architecture there has been considerable work reported in literature on its performance evaluation. However, none of them have addressed the basic issue of quantification of QoS for supporting streaming media. The main contribution in this paper is the quantification of the QoS of streaming media in terms of mean opinion score (MOS) values. A test bed has been implemented using off-the-shelf components. The experimental results and MOS values are used to show that in a DiffServ assured forwarding network architecture, with class based weighted fair queue scheduling discipline, the QoS of streaming media is not compromised when the load exceeds the reserved capacity, even in case of congestion

WEB SERVICE
Definition:
 A web service is a collection of protocols and standards used for exchanging data between applications or systems.  A Web service is a method of communication between two electronic devices over a network.  The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network.  Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Web services are characterised by their great interoperability and extensibility, as well as their machineprocessable descriptions Characteristics of Web services

Characteristics of Web services:

     Providing services to other computer programs (not to Web browsers) Interoperability between software applications running on different computers Loosely coupled Machine-processable Use of standards: XML, HTTP, SOAP, WSDL.

Example: A simple Web service

1. Creating a simple HelloWorld Web service in Java prepanding Hello to its input 2. Deploying the Web service on a Web server (GlassFish) 3. Calling the Web service from Ruby

Web services standards:

One of the key attributes of Internet standards is that they focus on protocols and not on implementations. The Internet is composed of heterogeneous technologies that successfully interoperate through shared protocols. This prevents individual vendors from imposing a standard on the Internet. Open Source software development plays a crucial role in preserving the interoperability of vendor implementations of standards. The following standards play key roles in Web services: Universal Description, Discovery and Integration (UDDI), Web Services Description Language (WSDL), Web Services Inspection Language (WSIL), SOAP, and Web Services Interoperability (WS-I). The relationship between these standards is described in Figure 2.

XML: Extensible Markup Language (XML) is a extensible, portable, and structured text format. XML is playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. XML was derived from SGML, which was a complex language for defining other markup languages. XML initiative consists of bunch of related standards. Apart from the core XML standard, it includes XSLExtensible Stylesheet language, which is used to transform XML data into a customizable presentation. XLink and XQuery provide a way to provide flexible query facilities to extract data from real and virtual XML documents on the Web. XPath and XPointer are languages for addressing parts of an XML document. UDDI : The UDDI specification defines open, platform-independent standards that enable businesses to share information in a global business registry, discover services on the registry, and define how they interact over the Internet. For more information on UDDIWSIL is an XMLbased open specification that defines a distributed service discovery method that supplies references to service descriptions at the service provider's point-of-offering, by specifying how to inspect a Web site for available Web services. A WSIL document defines the locations on a Web site where you can look for Web service descriptions. Since WSIL focuses on distributed service discovery, the WSIL specification complements UDDI by facilitating the discovery of services that are available on Web sites that may not be listed yet in a UDDI registry. WSDL: WSDL is an XML-based open specification that describes the interfaces to and instances of Web services on the network. It is extensible, so endpoints can be described regardless of the message formats or network protocols that are used to communicate. Businesses can make the WSDL documents for their Web services available though UDDI, WSIL, or by broadcasting the URLs to their WSDL via email or Web sites. WSDL is described as a separate topic in this documentation. For more information on WSDL SOAP : SOAP is an XML-based standard for messaging over HTTP and other Internet protocols. It is a lightweight protocol for the exchange of information in a decentralized, distributed environment. It is based on XML and consists of three parts:
y y y

An envelope that defines a framework for describing what is in a message and how to process it. A set of encoding rules for expressing instances of application-defined data types. A convention for representing remote procedure calls and responses.

SOAP enables the binding and usage of discovered Web services by defining a message path for routing messages. SOAP may be used to query UDDI for Web services. Figure 2. Relationships between SOAP, UDDI, WSIL and WSDL.

A service provider hosts a Web service and makes it accessible using protocols such as SOAP/HTTP or SOAP/JMS. The Web service is described by a WSDL document that is stored on the provider's server or in a special repository. The WSDL document may be referenced by the UDDI business registry and WSIL documents. These contain pointers to the Web service's WSDL files. The WS-I Simple SOAP Binding Profile and WS-I Attachments Profile are outlines of requirements to which WSDL and Web service protocol (SOAP/HTTP) traffic must comply in order to claim WS-I conformance. The Web services WS-I validation tools currently support WS-I Simple SOAP Binding Profile 1.0 and the Attachment Profile 1.0. Several new Web services standards are also supported by this development environment. These include:

JAX-RPC JAX-RPC stands for Java API for XML-based RPC, also known as JSR 101. It is a specification that describes Java Application Programming Interfaces (APIs) and conventions for building Web services and Web service clients that use remote procedure calls (RPC) and XML. It standardizes the Java to WSDL and WSDL to Java mappings, and provides the core APIs for developing and deploying Web services and Web service clients on the Java platform. For more information refer to the official specifications. JSR-109 JSR-109 (Implementing Enterprise Web Services) defines the programming model and run-time architecture to deploy and look up Web services in the Java EE environment; more specifically, in the Web, EJB, and Client Application containers. One of its main goals is to ensure vendors' implementations interoperate. For more information, refer to the official specifications:
y y

JSR-109 JSR-921

WS-S These tools support the OASIS Web Services Security 1.0 standard. For more information on the various components of this standard, refer to:
y y y

Web Services Security: SOAP Message Security V1.0 Web Services Security: Username Token Profile V1.0 Web Services Security: X.509 Token Profile V1.0

Issues of Web Service:

 Long running business processes  Transaction: What to do when something goes wrong Compensation Handler

QUALITY OF WEB SERVICE :

Quality Of Service:
Quality is defined as: The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs  Stated needs are explicitly declared by the users  Implied needs refers to requirements users do not know

When QoS :
     Before building a service the offered QoS must be defined Class of Service Before using a service provider and user must agree on QoS Service Level Agreement So, both service and providers must share the same lexicon for expressing QoS

Why QoS :
 Differentiates functionally equivalent services  Users:  Can express their needs  Can select the best service with respect to their needs  Providers:  Can better advertise their services  Adaptivity  Self-healing

QoS Principles
Five principles govern the construction of QoS architectures. These are the principles of integration, separation, transparency, asynchronous resource management and performance. Integration Principle The integration principle states that quality of service must be configurable, predictable and maintainable over all architectural layers to meet end-to-end quality of service [Campbell,93]. Flows traverse resource QoS modules (e.g., CPU, memory, devices, network) at each layer from source media devices, down through the source protocol stack, across the network, up through the receiver protocol stack to the playout devices. Each QoS module traversed must provide QoS configurability (based on a QoS specification), resource guarantees (provided by QoS control mechanisms) and maintenance (based on monitoring mechanisms) of on-going flows.

Separation Principle The separation principle states that media transfer, control and management are functionally distinct architectural activities [Lazar,92]. The separation principle states that these activities should be separated in architectural frameworks. One aspect of separation is the distinction between signalling and media-transfer. Flows, which are isochronous in nature, generally require a wide variety of high bandwidth, low latency, non-assured services with some form of jitter correction at the playout devices. On the other hand, signalling, which is full duplex and more asynchronous in nature, generally requires low bandwidth, assured-type services with no jitter constraint. Transparency Principle The transparency principle states that applications should be shielded from the complexity of underlying QoS specification and QoS management functions such as QoS monitoring and maintenance. An important aspect of transparency is the QoS-based API [Campbell,94] [Bansal,95] at which desired quality of service levels are stated (see QoS management policy in Chapter 4). The benefit of transparency is three-fold. It reduces the need to embed quality of service functionality in applications. It hides the detail of underlying service specification from the application and it delegates the complexity of handling QoS management activities to the underlying QoS framework. Asynchronous Resource Management Principle The asynchronous resource management principle [Lazar,92] guides the division of functionality between architectural modules and pertains to the modeling of control and management mechanisms. It is necessitated by, and is a direct reflection of fundamental time constraints that operate in parallel between activities (e.g., scheduling, flow control, routing, QoS management) in distributed communications environments. The state of the distributed communication system is structured according to these different time scales. The operating point of communication activities is arrived at via asynchronous algorithms that operate and exchange control data periodically among each other. Performance Principle Finally, the performance principle subsumes a number of widely agreed rules for QoS driven communications design and implementation. These rules guide the division of functionality in structuring communication protocols for high performance in accordance with Saltzers systems design principles [Saltzer,84], avoidance of multiplexing [Tennenhouse,90], recommendations for structuring communications protocols such as application layer framing and integrated layer processing [Clark,90], and the use of hardware assists for protocol processing [Chesson,88] [Zitterbart,92].

QoS Specification
QoS specification is concerned with capturing application level quality of service requirements and management policy and is generally different at each system layer and is used to configure and maintain QoS mechanisms resident at each layer. For example, at the distributed system platform level QoS specification is primarily user-oriented rather than system-oriented. Lower-level considerations such as tightness of synchronisation for multiple related transport flows, or the rate and burst size of flows, or the details of thread

scheduling should all be hidden at this level. QoS specification is therefore declarative in nature; users specify what is required rather than how this is to be achieved by underlying QoS mechanisms. Quality of service specification encompasses the following areas: Flow Synchronisation ("Orchestration") Specification Flow synchronisation specification characterises the degree (i.e., tightness) of synchronisation between multiple related flows [Little,90]. For example, simultaneously recorded video perspectives (shown as video 1 and 2 in figure 2.1) must be played in precise frame by frame synchrony so that relevant features may be simultaneously observed. On the other hand, lip synchronisation in multimedia flows does not need to be absolutely precise when the main information channel is auditory and video is only used to enhance the sense of presence. Flow performance specification Flow performance specification characterises the user's flow performance requirements [Partridge,92]. The ability to guarantee traffic throughput rates, delay, jitter and loss rates, is particularly important for multimedia communications. These performance-based metrics are likely to vary from one application to another. To be able to commit necessary endsystem and network resources a QoS architecture one must have prior knowledge of the expected traffic characteristics associated with each flow before resources can be committed and resource guarantees made. QoS Commitment QoS commitment specifies the degree of end-to-end resource commitment required (e.g., deterministic [Ferrari,90], predictive [Clark,92], adaptive [Campbell,95] and best -22effort). While the flow performance specification permits the user to express required performance metrics in a quantitative manner, QoS commitment allows these requirements to be refined in a qualitative way so as to allow a distinction to be made between hard, firm and soft performance guarantees. QoS commitment expresses a degree of certainty that the QoS levels requested at flow establishment or re-negotiation will actually be honoured. QoS Management Policy QoS management policy captures the degree of QoS adaptation [Campbell,95] (continuous or discrete) that a flow can tolerate and scaling actions to be taken in the event of violations in the contracted QoS [Campbell,95]. By trading-off temporal and spatial quality to available bandwidth, or manipulating the playout time of continuous media in response to variation in delay, audio and video flows can be presented at the playout device with minimal perceptual distortion. The QoS management policy also includes user-level selection of QoS indications (called event QoS signals) in the case of violations in the requested quality of service, and periodic bandwidth, delay, jitter and loss notification (i.e., QoS signals) which are suitable for adaptive applications [Shenker,93a].

Cost of Service Cost of service specifies the price the user is willing to incur for the level of service; cost of service is an important factor when considering QoS specification. If there is no notion of cost involved in QoS specification, there is no reason for the user to select anything other than maximum level of service (e.g., guaranteed QoS at peak rate). This philosophy would inevitably lead to resource inefficiencies. To counter this condition the cost function must incorporate pricing differentials [Chocchi,91] to encourage the user to select the optimum QoS commitment and performance QoS parameters such as a lowercommitmentcosts-less pricing policy.

Web service QoS requirements

The major requirements for supporting QoS in Web services are as follows:
y

Availability: Availability is the quality aspect of whether the Web service is present or ready for immediate use. Availability represents the probability that a service is available. Larger values represent that the service is always ready to use while smaller values indicate unpredictability of whether the service will be available at a particular time. Also associated with availability is time-to-repair (TTR). TTR represents the time it takes to repair a service that has failed. Ideally smaller values of TTR are desirable. Accessibility: Accessibility is the quality aspect of a service that represents the degree it is capable of serving a Web service request. It may be expressed as a probability measure denoting the success rate or chance of a successful service instantiation at a point in time. There could be situations when a Web service is available but not accessible. High accessibility of Web services can be achieved by building highly scalable systems. Scalability refers to the ability to consistently serve the requests despite variations in the volume of requests. Integrity: Integrity is the quality aspect of how the Web service maintains the correctness of the interaction in respect to the source. Proper execution of Web service transactions will provide the correctness of interaction. A transaction refers to a sequence of activities to be treated as a single unit of work. All the activities have to be completed to make the transaction successful. When a transaction does not complete, all the changes made are rolled back. Performance: Performance is the quality aspect of Web service, which is measured in terms of throughput and latency. Higher throughput and lower latency values represent good performance of a Web service. Throughput represents the number of Web service requests served at a given time period. Latency is the round-trip time between sending a request and receiving the response. Reliability: Reliability is the quality aspect of a Web service that represents the degree of being capable of maintaining the service and service quality. The number of failures per month or year represents a measure of reliability of a Web service. In another sense, reliability refers to the assured and ordered delivery for messages being sent and received by service requestors and service providers. Regulatory: Regulatory is the quality aspect of the Web service in conformance with the rules, the law, compliance with standards, and the established service level agreement.

Web services use a lot of standards such as SOAP, UDDI, and WSDL. Strict adherence to correct versions of standards (for example, SOAP version 1.2) by service providers is necessary for proper invocation of Web services by service requestors. Security: Security is the quality aspect of the Web service of providing confidentiality and non-repudiation by authenticating the parties involved, encrypting messages, and providing access control. Security has added importance because Web service invocation occurs over the public Internet. The service provider can have different approaches and levels of providing security depending on the service requestor.

Limitations
To date, most of the developments in the provision of quality of service support have occurred in the context of individual architectural layers. Much less progress has been made in addressing the issue of end-to-end QoS for multimedia communications. There has been, however, considerable progress in the separate areas of Open Distributed Processing (ODP), end system and network support for quality of service. In end-systems, most of the progress has been made in the specific areas of scheduling, flow synchronisation and transport support. In networks, research has focused on providing suitable traffic models and service disciplines, as well as appropriate admission control and resource reservation protocols. Many current network architectures, however, address quality of service from a providers point of view and analyse network performance, comprehensively failing to address the quality needs of applications. Until recently there was little work on quality of service support in distributed systems platforms. Such work has been done in the context of the Open Distributed Processing ISO standard in SC21. The essential characteristics of the current state of QoS research can be summarised as follows: i) incompleteness in service: current service interfaces are generally not QoS configurable and provide only a subset of the facilities needed for control and management of continuous media; ii) lack of mechanisms to support QoS guarantees: research is needed in distributed control, monitoring and maintenance QoS mechanisms so that contracted levels of service can be predictable and assured; iii) lack of continuity: current QoS initiatives are primarily network-centric and do not address the suitability of network QoS semantics extended in to the end-system, i.e., can ATM Forum, int-serv and ISO QoS models be extended successfully to the distributed platform and operating system environments or is there an intrinsic discontinuity? and iv) lack of overall framework: it is necessary to develop an overall architectural framework to build on and reconcile the existing notion of quality of service at different systems levels and among different network architectures.

Conclusion
Quality of services is an important requirement of business-to-business transactions and thus a necessary element in Web services. The various QoS properties such as availability, accessibility, integrity, performance, reliability, regulatory, and security, need to be addressed in

the implementation of Web service applications. The properties become even more complex when you add the need for transactional features to Web services. Some of the limitations of protocols such as HTTP and SOAP may hinder QoS implementation, but there are a number of ways to provide proactive QoS in Web services.

REFERENCE http://citeseerx.ist.psu.edu/ http://www.opensourcetutorials.com/ http://ieeexplore.ieee.org/ http://en.wikipedia.org/wiki/Web_service http://www.scribd.com http://www.google.co.in/ https://publib.boulder.ibm.com/infocenter/ratdevz/v8r0/index.jsp?topic=/org.ecl ipse.jst.ws.doc.user/concepts/cwsstandards.html http://msdn.microsoft.com/en-us/library/ms951274.aspx www.w3.org/TR/wsdl http://www.w3schools.com/webservices/ws_intro.asp

PROBLEM STATEMENT

Developing a model for measuring the reusability of service by quantifying the quality of service