0018-9162/07/$25.00 © 2007 IEEE February 2007 59P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

R E S E A R C H F E A T U R E

replies are four to five times larger if implemented as a Web service.3 Parsing XML code also adds extra com-puting costs.

Compressing Web service interactions is thereforedesirable. Although compression and decompressionrequire more computing power, compression is still use-ful in many cases because decompression causes analmost negligible performance loss3 and wireless trans-mission consumes far more energy than CPU opera-tions.4 Further, service providers charge mobile clientsby volume rather than by connection time.

WS-QOS FRAMEWORKFrom the client’s point of view, a QoS-aware Web ser-

vice communication process consists of three phases:

• specification of QoS requirements,• QoS-aware service discovery and selection, and• application of the specified QoS to the service

invocation.

Several proposed standards target QoS specificationsfor Web services.5 For example, IBM’s Web ServiceLevel Agreement framework6 and the Web ServiceManagement Language7 applied in Hewlett-Packard’sOpen View Internet Services define XML schemas tospecify individually negotiated customized service-level

Web services providers can use the WS-QoS framework to achieve QoS differentiation by

integrating various aspects of distinct communication layers. An architecture based on the

framework supports resource-constrained mobile devices, which will generate a large

percentage of Web service requests in the future.

Min Tian, MJN Technologies

Andreas Gramm, Hartmut Ritter, and Jochen H. Schiller, Freie Universität Berlin

Thiemo Voigt, Swedish Institute of Computer Science

A s Web services become increasingly popular,more businesses are building their future solu-tions around Web service technology. For ser-vice providers, quality of service is a key aspectof this technology. Although service offers with

no QoS guarantees are acceptable in some simple sce-narios, QoS is critical in selecting Web services as build-ing blocks in more sophisticated business applications.1

For this reason, standards such as the Business ProcessExecution Language for Web Services (BPEL4WS) incor-porate security, reliability, accessibility, and other QoSfeatures.2 WS-Interoperability (www.ws-i.org) specifi-cations also address high-level QoS support.

Two demands are driving the need for QoS specifica-tions in Web services. On one hand, clients seek reliableservice performance whenever the need arises. On theother hand, service providers strive to achieve an opti-mal balance between user satisfaction and system uti-lization; for example, crucial transactions such aspayment should be executed at high priority.

Given the ubiquity of mobile devices, clients usingthem will likely generate a large percentage of all Webservice requests in the future. However, mobile devicesare resource-constrained in terms of CPU, memory, andbattery life. This is problematic because, compared totraditional Web interaction, Web services impose addi-tional overhead. For example, SOAP requests and

Adaptive QoS for Mobile WebServices through Cross-LayerCommunication

rqTian.qxp 23/1/07 12:16 PM Page 59

60 Computer

agreements. These SLAs feed intoengines that monitor SLA complianceat runtime.

We developed the Web Service QoSframework to support all threephases. WS-QoS

• lets both service clients and serviceproviders specify requests andoffers with QoS properties andclasses;

• enables efficient service offer dis-covery and selection to acceleratethe overall lookup process forclients;

• provides a flexible way for serviceproviders to publish and updateservice offers with different QoSaspects; and

• supports QoS-aware service invo-cation and response at runtime toimprove overall performance.

Previous work discussed WS-QoS inthe context of specification as well as discovery andselection of Web services.8,9 Here, we focus on the thirdphase: how both transport and application serviceproviders can use the framework to support mobile Webservice clients and providers in defining diverse QoS cri-teria as well as in selecting the most appropriate serviceprovider.

By applying the WS-QoS XML schema, providers canaugment their Web service offers with various QoSaspects such as delay, bandwidth, jitter, and packet losswhile clients can define their own QoS requirements.While predefined parameters enable efficient compari-son of QoS offers, in some cases the need to extendexisting definitions arises. Therefore, both serviceclients and providers can define custom parameters byreferring to a specific entry in a WS-QoS ontology,which the URL of the file containing its definitionuniquely identifies. In this way, any WS-QoS-awareinstance can compare both standard and custom para-meters automatically.

Our approach considers the various layers involvedin Web service communication, thereby ensuring effi-cient utilization of the underlying resources as well asbetter support of application-dependent requirements.Providers can map clients’ QoS requirements relating tothe transport network onto the actual underlying QoS-aware network technology at runtime. They can alsoperform server-side request differentiation and use non-compulsory asymmetric compression of the SOAP mes-sage body to support mobile devices with lowconnectivity and limited power supply while maintain-ing server performance.

WEB SERVICE BROKERTo enable efficient and accelerated QoS-aware service

discovery and selection, the framework extends the stan-dard Web service interaction model10 to include a Webservice broker. A Web service client contacts the WSBto look up services in one or more UDDI registries ratherthan looking them up on its own. The WSB holds up-to-date information on offers currently available for agroup of recently requested services. Offers are groupedby the interface that the services implement.

Figure 1 depicts the QoS-aware service discovery,selection, and invocation process. This process consistsof nine steps:

1. Service providers publish their Web services, uniquelyidentified by an interface key, to UDDI registries.

2. Clients request services from the WSB that imple-ment a certain interface and comply with the QoSrequirements.

3. We assume that WSBs continually analyze the mar-ket and interesting service offers in advance. Byprefetching information about offers in which clientsmight be interested, the WSB can significantly accel-erate lookup. If the WSB does not already have cur-rent information on offers that meet the clients’requirements, it requests Web services according tothe interface key from one or more UDDI registries.

4. The UDDI registries return a list of services thatimplement the interface key.

5. The WSB asks the service providers for servicedescriptions, such as Web Service DescriptionLanguage (WSDL) files, with WS-QoS extensions.

Clientapplication

Offerbroker

Serviceprovider

UDDIregistry

QoSrequirements

Selectedoffer

Invokeservice

2

9

InterfacekeyRequest

services3

Serviceinformation

Getservices

4

Offers inWSDLGet

servicedescription6

QoSrequirements

Interfacekey

Requestservice

8

Interfacekey

Get bestservice

1

Interfacekey

Publishservice

5

Request servicedescription

7

Test offers againstclient requirements

Figure 1. QoS-aware service discovery, selection, and invocation process. From the

client’s point of view, the Web service broker reduces the number of steps from nine

to four.

rqTian.qxp 23/1/07 12:16 PM Page 60

February 2007 61

6. The service providers return their service descrip-tions with QoS offers.

7. The WSB tests the offers, which are updated at reg-ular intervals, against the clients’ requirements.

8. The WSB returns the most appropriate service to theclient.

9. The client directly invokes the service with the orig-inal QoS requirements.

From the client’s point of view, the WSB reduces inter-action from these nine steps to just four (2, 7, 8, and 9),sharply reducing lookup time. Our own tests reveal thata client needs approximately 4,860 milliseconds to findan appropriate offer when it has to look up and selectservices by itself; if a client uses the WSB and it alreadyhas the offer list, service discovery takes only 385 ms.

ADAPTIVE QOS DELIVERY In the WS-QoS framework, a client defines different

QoS parameters according to different layers—forexample, delay and jitter in the transport layer, contentcompression and decompression in the SOAP layer, andresponse time and server availability in the Web serviceapplication layer. Various components dedicated to eachlayer interpret and perform these definitions, which aremaintained in the Web service layer.

Figure 2 depicts this cross-layer architecture duringthe third phase of a mobile Web service communicationprocess. We assume that the radio bearer supports bothQoS and QoS classes as do the Universal MobileTelecommunications System (UMTS) and the GeneralPacket Radio Service (GPRS), and that the wired net-work supports Diffserv technology.

Mapping transport priorities WS-QoS SOAP message headers contain client-spec-

ified QoS requirements. The following is a typicaltransportQoSPriorities entry in the framework’s XMLschema for MyOperation():

<?xml version="1.0" encoding="utf-8" ?><wsqos xmlns="http://wsqos.org/">

…<operationQoSInfo name="MyOperation">…<transportQoSPriorities><delay>5</delay><jitter>3</jitter><throughput>8</throughput><packetLoss>3<packetLoss>

</transportQoSPriorities>…

</operationQoSInfo>…</wsqos>

In this case, the operation expects a low data rate(throughput = 8), in-time delivery (jitter = 3), and a lowpacket loss rate (packetLoss = 3)—akin to a low-qualityvoice stream.

Every participating component along the communi-cation path can evaluate the SOAP header, enablingcross-layer QoS differentiation. Since concrete QoS met-rics vary with network technologies, we define priori-ties ranging from 1 to 10 in a transportQoSPrioritieselement. The smaller the priority value, the higher therequirement.

A technology-specific network proxy then evaluatesthe priorities and maps the specified requirements intoa corresponding traffic class. We have implemented sucha proxy for Diffserv networks that applies expeditedforwarding for a priority of 1 or 2, assured forwardingfor priorities between 3 and 8, with drop precedencedepending on the packet loss priority, and best-effortforwarding for a priority of 9 or 10.

In this example, a QoS proxy running on the mobileclient translates the QoS requirements according to thetransport QoS priorities to the corresponding UMTSQoS class and performs signaling with the UMTS sys-tem. Since both Diffserv and UMTS support QoSclasses, the access point (AP) can now map the UMTSQoS class to a corresponding Diffserv code point(DSCP). This occurs without any knowledge of the WS-QoS framework.

Optionally, if the AP supports WS-QoS, it could mapthe client’s requirement to a correspondingDSCP by evaluating the QoS information inthe WS-QoS SOAP header. Although thisenables finer mapping granularity, processingthe SOAP header leads to performance loss.Since this header is only present in the first ofseveral IP packets carrying a SOAP message,the AP must perform per-flow management,which causes scalability problems. The simplemapping of UMTS and DSCP classes is there-fore preferable when the AP experiences hightraffic load.

The intermediate Diffserv-enabled routersmanage the traffic depending on the DSCP.

Mobile client Access point Router Web service server

Radio bearer with QoS classes Wired network with QoS classes

Figure 2. Cross-layer architecture.The WS-QoS framework achieves adap-

tive QoS delivery through cross-layer communication.

rqTian.qxp 23/1/07 12:16 PM Page 61

62 Computer

Upon receiving the client’s request, the server processesthe response. When the server sends the response, it putsthe client’s QoS requirements into the SOAP headeragain. A server-side QoS proxy then evaluates the QoSinformation and marks the DSCP in each IP packetaccordingly. The intermediate routers transmit the IPpackets according to the DSCP. The AP maps theDiffserv class to a corresponding UMTS class.

Adaptive server performanceThe following serverQoSMetrics element of a WS-QoS

definition specifies server performance in terms of pro-cessing time, throughput, availability, and reliability:

<serverQoSMetrics><processingTime>5</processingTime><requestsPerSecond>30</requests

PerSecond><reliability>0.99</reliability><availability>0.98<availability>

</serverQoSMetrics>

Clearly, these parameters are interdependent. A serviceoffer defines a distinct level of service performance.Request differentiation can take place on various levels.The current WS-QoS implementation performs requestdifferentiation on the application level. Response timesare influenced by setting the priority of the thread pro-cessing the request according to the clients’ requirements.

While we employ a simple prioritization mechanism,more elaborate request differentiation approaches couldbe applied to distinguish server performance levels. Forexample, availability of different resources that a Webserver provides can be differentiated at the OS level.11

Such an approach guarantees prioritized access to a lim-ited scope of resources even on overloaded servers.

Adaptive message load compressionAlthough mobile hardware CPU power and memory

are increasing rapidly, improving battery life and wire-less data transmission rates remain active research chal-lenges. Therefore, considering both aspects in mobilecomputing is essential.

The same algorithm need not perform compressionand decompression on mobile devices. Using the low-est-energy compressor and decompressor on a mobiledevice can reduce energy consumption by up to 30 per-cent.4 Further, wireless transmission of a bit can require1,000 times more energy than a single 32-bit computa-tion.4 Compression is one way to deal with Web ser-vices’ large message sizes.3 It is also useful for managingpoorly connected clients with resource-constraineddevices despite the CPU time required for decompress-ing the responses.

When a Web service client requests a small amount ofSOAP content over HTTP, most of the conversation con-

sists of HTTP headers, SOAP headers including theXML schema, and brackets. For example, if a clientsends an ISBN to find out about a book, the Web ser-vice accepts the number as the input parameter andreturns the book information as a data set. The actualcontent of both request and response totals 589 bytes—10 bytes for the ISBN and the rest for information aboutthe book—but more than 3,900 bytes must be sent andreceived for the entire conversation. The disproportionis not as great for traditional Web interaction withHTML, which is about 1,200 bytes.

Because server decompression consumes negligibleenergy, mobile clients should request data from theserver in a format that facilitates low-energy decom-pression to reduce decompression energy.4

Compression generally decreases server performancedue to the additional CPU time required. A lightlyloaded server can afford the extra cost of compressingresponses. The throughput of a heavily loaded servercan decrease substantially when it is required to com-press Web service responses.3 At the same time, theresponse times experienced by clients increase.

We have proposed a simple scheme that lets clientsspecify whether they want to receive data compressedwhen requesting a Web service.3 Depending on the cur-rent server load, the server compresses only the requestsof those clients that required such a service. Experimentalresults demonstrate both the feasibility and good per-formance of this approach. Both the server and clientswith poor connectivity benefit during high server de-mand, while the server is protected from overload dueto compression.

To signal what type of compression to use, weextended the securityAndTransaction node of theoperationQoSInfo element in our WS-QoS XML schemawith two subnodes, compression and decompression, asthe following example shows:

<securityAndTransaction name="compression" requires="one">

<protocol name="zlib" ontology= "http://www.mydomain.com/compression.wsqos"/>

<protocol name="bzip2" ontology="http://www.mydomain. comcompression.wsqos"/>

</securityAndTransaction><securityAndTransaction

name="decompression" requires="one"><protocol name="bzip2" ontology= "http://www.mydomain.com/compression.wsqos"/>

<protocol name="zlib" ontology= "http://www.mydomain.com/compression.wsqos"/>

</securityAndTransaction>

rqTian.qxp 23/1/07 12:16 PM Page 62

February 2007 63

9. M. Tian et al., “Efficient Selection and Monitoring of QoS-Aware Web Services with the WS-QoS Framework,” Proc.IEEE/WIC/ACM Int’l Conf. Web Intelligence, IEEE CS Press,2004, pp. 152-158.

10. H. Kreger, “Web Services Conceptual Architecture (WSCA1.0),” white paper, IBM Research Group, May 2001; www-306.ibm.com/software/solutions/webservices/pdf/WSCA.pdf.

11. R. Pandey, J.F. Barnes, and R. Olsson, “Supporting Qualityof Service in HTTP Servers,” Proc. 17th Ann. ACM Symp.Principles of Distributed Computing, ACM Press, 1998, pp.247-256.

12. T. Voigt and P. Gunningberg, “Adaptive Resource-Based WebServer Admission Control,” Proc. 7th Int’l Symp. Computersand Communication, IEEE CS Press, 2002, pp. 219-224.

Min Tian is CEO of MJN Technologies, China. Hisresearch interests include QoS, Web services, mobile com-puting, and mobile consumer electronics. Tian received aPhD in computer science from the Freie Universität Berlin.Contact him at sky@skyfield.de.

Andreas Gramm, a contributor to this article while a stu-dent at the Institute of Computer Science, Freie UniversitätBerlin, now teaches computer science at Menzel-Oberschulein Berlin. His research interests include software engineer-ing and telematics. Gramm received an MSc in computerscience from the Freie Universität Berlin. Contact him atandreas@gramm.de.

Hartmut Ritter is an assistant researcher and lecturer in theComputer Systems and Telematics working group at theInstitute of Computer Science, Freie Universität Berlin. Hisresearch interests include mobile communications, embed-ded Internet design, and sensor networks. Ritter received aPhD in computer science from the Universität Karlsruhe,Germany. He is a member of the IEEE Computer Society.Contact him at hritter@inf.fu-berlin.de.

Jochen H. Schiller is a professor and heads the ComputerSystems and Telematics working group at the Institute ofComputer Science, Freie Universität Berlin. His researchfocuses on wireless, mobile, and embedded devices; com-munication protocols; operating systems for small-footprintdevices; and QoS in communication systems. Schillerreceived a PhD in computer science from the UniversitätKarlsruhe. He is a member of the IEEE Computer Society.Contact him at schiller@computer.org.

Thiemo Voigt is a senior researcher at the Swedish Instituteof Computer Science. His research focuses on wireless sen-sor networks. Voigt received a PhD in computer sciencefrom Uppsala University, Sweden. He is a member of theIEEE Computer Society. Contact him at thiemo@sics.se.

The servers announce which decompression algo-rithms they support, while the clients define which com-pression algorithm a server must use to compressresponses. Algorithms are listed in order of preference toensure the most appropriate match.

A n integrated QoS solution should always considerthe various QoS aspects of distinct communicationlayers. Enabling different layers to communicate

with one another requires broader research. Higher lay-ers should be prepared to consume QoS provided bylower layers, and lower layers should actively provideQoS that complies with upper-layer requirements.Carefully mapping this cross-layer communicationrequires components with some degree of intelligence.We are now building a testbed to conduct performancemeasurements of the complete WS-QoS architecture.

Our future plans calls for combining the frameworkwith wireless sensor networks. The consensus amongresearchers is that sensor networks need an access pointto collect data from and send commands. Mobile andwireless devices could act as APs from the sensor net-works’ point of view. Because sensor nodes are evenmore resource-constrained than such devices, we aregoing to extend WS-QoS to allow Internet access to sen-sor networks through Web services. ■

References

1. D.A. Menascé, “QoS Issues in Web Services,” IEEE InternetComputing, vol. 6, no. 6, 2002, pp. 72-75.

2. K. Chiu, M. Govindaraju, and R. Bramley, “Investigating theLimits of SOAP Performance for Scientific Computing,” Proc.11th Int’l Symp. High-Performance Distributed Computing,IEEE CS Press, 2002, pp. 246-254.

3. M. Tian et al., “Performance Considerations for Mobile WebServices,” Computer Communications, vol. 27, no. 11, 2004,pp. 1097-1105.

4. K. Barr and K. Asanovic, “Energy Aware Lossless Data Com-pression,” Proc. 1st Int’l Conf. Mobile Systems, Applications,and Services, ACM Press, 2003, pp. 231-244.

5. M. Tian et al., “A Survey of Current Approaches towardsSpecification and Management of Quality of Service for WebServices,” PIK, vol. 27, no. 3, 2004, pp. 132-140.

6. A. Keller and H. Ludwig, “The WSLA Framework: Specify-ing and Monitoring of Service Level Agreements for Web Ser-vices,” J. Network and Systems Management, vol. 11, no. 1,2003, pp. 57-81.

7. A. Sahai, A. Durante, and V. Machiraju, Towards AutomatedSLA Management for Web Services, tech. report HPL-2001-310R1, HP Labs, 2001; www.hpl.hp.com/techreports/2001/HPL-2001-310R1.pdf.

8. M. Tian et al., “A Concept for QoS Integration in Web Ser-vices,” Proc. 4th Int’l Conf. Web Information Systems Eng.Workshops, IEEE CS Press, 2003, pp. 149-155.

rqTian.qxp 23/1/07 12:16 PM Page 63