An Efficient Dual Caching Strategy for Web ServiceEnabled PDAs Xin Liu
Ralph Deters
MADMUC Lab University of Saskatchewan Saskatoon, S7N5C9, CANADA +1 306 966 2072
MADMUC Lab University of Saskatchewan Saskatoon, S7N5C9, CANADA +1 306 966 2072
[email protected]
[email protected]
ABSTRACT
1. PDA
PDAs have evolved over the years from resource constrained devices that supported only the most basic tasks to powerful handheld computing devices. However, the most significant step in the evolution of PDAs was the introduction of wireless connectivity which enabled them to host applications that require internet connectivity like email, web browsers and maybe most importantly smart/rich clients. Being able to host smart clients allows the users of PDAs to seamlessly access the IT resources (e.g. legacy apps) of their organizations. One increasingly popular way of enabling access to IT resources is by using Web Services (WS) [14]. This trend has been aided by the rapid availability of Web Service (WS) packages/tools, most notably the efforts of the Apache group [1] and IDE vendors (e.g., Microsoft’s Visual Studio [2], IBM’s Eclipse [3]). Using IDE tools and other software packages it is fairly easy for programmers to expose application interfaces and/or consume existing interfaces leading to a gradual replacement of the current web server centric approaches (e.g. ASP, JSP, Servlets, CGI scripts) with WS centric approach.
Apple’s Newton (1992 - 98), the first commercially available Personal Digital Assistant (PDA), was a resource and connectivity constrained device (8 MB RAM, infrared connection, serial Port) designed to support users with simple data processing/collecting tasks. While being a commercial failure, the Newton succeeded in popularizing the idea of the PDA and thus created a new type/market of computational devices. The ongoing evolution of PDAs has lead to resource rich devices like the IPaq hx2790 (256 MB, PXA70 624 MHz, 240 x 320 display with 65,536 colors) that offer computational resources comparable to the desktops of just a few year ago. However the most significant improvement for PDAs in recent years is the standardization of the software platform (Palm-OS, Microsoft-Windows Pocket-PC, Linux) and the integration of 802.11a/b as well as Bluetooth. The introduction of standard OS and standardized wireless communication has enabled the PDA to evolve beyond a simple data processing/collecting device that required frequent synchronization with the desktop. The ability to connect wireless to a network enables users to use their PDAs in much the same way they use their desktops. Besides the calendar and address book features, PDAs are capable of hosting web browsers, email clients, and thanks to the standardization of the OS, smart clients to legacy business applications. As a result the modern PDAs enable users to perform complex tasks (business processes) and thus supports a spatial decoupling of users from their main computational resources.
This paper focuses on the challenges of enabling PDAs to host Web Services consumers and introduces a dual caching approach to overcome problems arising from temporarily loss of connectivity and fluctuations in bandwidth.
Categories and Subject Descriptors C.2.4 [Distributed Systems]: Client/Server
General Terms 2. SOA
Web Services, SOA, Caching
Approximately at the same time the spatial decoupling of users from resources gained momentum, efforts to decouple IT components lead to the concept of service-orientation. ServiceOrientation (SO) [4] is a design & integration paradigm that is based on the notion of well defined, loosely coupled services. Within SO, services are viewed as computational elements that expose functionality in a platform-independent manner and can be described, published, discovered, orchestrated and consumed across language, platform and organizational borders.
Keywords Nomadic Web Services Client, Model-Based Caching Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’07, March 11-15, 2007, Seoul, Korea. Copyright 2007 ACM 1-59593-480-4/07/0003…$5.00.
The Service-Oriented Architecture (SOA) [5], first introduced by Gartner in 1996 [6], is a conceptual framework that identifies
788
However, the “standard” Web Services scenario assumes service providers and consumers as static and connected entities making it difficult for PDAs to participate. The main problem PDAs face is that by using wireless connections they are subjected to fluctuations in available bandwidth and frequent disconnects due to sudden signal loss.
service-consumers, service-providers and a registry trough which providers publish and consumer discover. While service-orientation (SO) can be achieved using different technologies, Web Services (WS) are the most commonly used due to the standardization efforts and the available tools/infrastructure.
This paper focuses on the development of a platform independent cache for resource rich handheld devices that use 802.11 style connections. The remainder of the paper is structured as follows. Section 3 provides an overview of the specific caching issues of nomadic Web Services clients. This is followed by a presentation of a model-driven caching framework designed to address these issues. The results of an empirical evaluation are presented in section 5. The paper concludes with a summary and an outlook.
Registry (UDDI Server in Web Services)
Pu b
s er ov sc
lis he
s
Di
3. Consuming Web Services with a PDA Standardization of protocols and the availability of Web Service packages make it fairly easy for application developers to enable handheld devices like PDAs to consume services. Since handheld devices are by nature mobile they represent mobile consumers.
Accesses
Service Provider
Service Consumer
Figure 1. Service-Oriented Architecture
Web Services (WS) are currently enjoying a wide support due to the acceptance of SO and the availability of Web Service packages/tools. Using IDE tools and other software packages it is now fairly easy for programmers to expose application interfaces and/or consume existing interfaces. As the XMLbased Web Services begin to emerge as the “lingua franca” for the development of loosely coupled distributed systems they become the preferred way for building large, distributed, heterogeneous systems. One of the most profound implications of the loose-coupling is the ease with which components (e.g. legacy systems) can be connected. By simply retrieving the service description (WSDL) from the provider it possible to automatically generate the stubs needed to communicate with the services. Consequently once services are deployed it is fairly easy to attach consumers like PDAs to them.
PDA
Notebook Wireless Link
LAN
Web Service Tablet PC Smartphone
Figure 3. Examples of mobile devices
A mobile consumer with a reliable connection appears to the service provider no different than a non-mobile consumer. Just like their non-mobile counterparts, they exchange XML documents (SOAP messages) as a means of communication. However if the mobile device experiences temporarily loss of connectivity it becomes a nomadic device/consumer. Nomadic Web Service consumers can encounter four basic types of interruption during communication:
Figure 2. Web Services Message Exchange
1.1) Connection Loss prior to request transmission The interaction between consumer and provider of services is achieved by exchanging SOAP messages. SOAP messages are XML documents that contain in their header and body elements all relevant information for issuing a request or returning the results of a request. The simplicity of the SOAP messages, the ability to define various MEP (Message Exchange Patterns) like Request-Response or Asynchronous-Call is one of the main reasons for the popularity and widespread use of WS.
1.2) Connection Loss during request transmission 2.1) Connection Loss prior to response transmission 2.2) Connection Loss during response transmission
789
principles (e.g. replay) to the area of XML SOAP caching. Since WSDL is insufficient as source of meta-data Ramasubramanian et al. [9] propose to add annotations in the WSDL specification to support the cache. The suggested annotations include semantic information such as cache-ability, life time, play-back, and default-response. This however leads to issues regarding standards and interoperability. Besides the general meta-data issues of caching, the nature of XML-based SOAP has been the focus of some research. Devaram [10] identifies XML encoding/decoding cost (in some cases up to 40%) as a main source for SOAP latency. Furthermore, a cache employing direct storage of SOAP request-response pairs is subject to severe cache busting, as identified by Takase et al. [8, 11]. Takase proposes XML canonicalization as an approach for eliminating cache busting. However, with more complex MEP (message exchange patterns) and consequently more data in the SOAP header, it is hard to achieve this canonicalization without meta-data. In many respects the design and handling of metadata emerges as the dominant issue in the context of Web Services caching.
It is important to note that scenarios 1.1 & 1.2 can be detected by the client whereas 2.1 & 2.2 can not. Since the communication between consumer and provider is achieved by exchanging SOAP messages it becomes possible to intercept and analyze these messages. WS tend to use the HTTP [13] protocol for their message exchange which makes the interactions of service consumer and service provider remarkably similar to “normal” web client-server interaction. Since caches have long been used to handle disconnectivity for nomadic clients they offer themselves readily as an approach for supporting nomadic WS consumers. Since the loss of connectivity can happen during the sending/receiving of request and during the sending/receiving or responses two caches are needed. On cache resides on the client side and one on the server side.
4. Model-Driven Caching of Web Srvices Figure 5 shows the architecture of the implemented modeldriven dual caching system. As mentioned in the previous section two transparent caches, one on the client side and one on the server side are required to overcome loss of connectivity during sending or receiving of SOAP traffic. The transparent client-side cache (CSC) shields in a transparent manner the service consumer from sudden loss of connectivity during the service call. To the client, the CSC appears as a local proxy residing on the mobile device. Whenever the client issues a request, the CSC first tries to serve the request from its cache. If this fails, the request is sent to the provider-side cache (PSC). The response will be cached on the CSC (if meta-data indicates that it is cacheable).
Figure 4. Dual Caching The client-side cache is designed to handle the problems 1.1 & 1.2 by queuing requests that could not be sent and to resend them soon as the connection gets reestablished, thus creating the illusion of seamless connectivity for short-lived disconnectivity. The provider-side cache is needed for storing and resending the responses from the provider that have not been successfully transmitted due to the consumers loss of connectivity thus avoiding confusion for the provider. Despite the considerable efforts spent on SOA and Web Services there seems to be a lack of research regarding the caching of service / Web Services. Friedman [7] discusses on a more abstract level aspects of caching Web Services in ad-hoc networks. The proposed architecture is similar to a P2P system in which some mobile devices are willing to server as ad-hoc routers, and that the system can use as proxy caches. One of the requirements of this work is that caching services must be able to cache both data and code. This approach may be feasible for tight-coupled interorganizational interactions. However, for the loose-coupled services in SOA and WS, the applicability of this approach can be doubted. The work of Terry et al. [8] can be seen as the most important in the area of Web Services caching. The work identifies the need for understanding the cachability (meta-data) of services as a key issue and introduces known caching
Figure 5. Dual Caching System Architecture
790
limited in its expressiveness, it needs to be augmented with semantic by use of a simplified OWL.
The PSC resides on a proxy server which has a reliable connection to the service provider. The incoming requests from the CSC are sent directly to the provider. Responses from the provider are first cached in the PSC and then sent to the CSC. In case the CSC can’t be reached the PSC will wait for the CSC to issue a reconnect message upon which the PSC will resubmit all queued responses.
The connectivity description contains statistics of precious connectivity recordings and serves as a mechanism for predicting the available bandwidth.
5. Experiments
The CSC and PSC use a cache-manager as the main coordination component. Both also use a hashtable to store the request-response pair that uses the request as the key and the response as the data. The hashtable is governed by an evictor component that is responsible for the management of the hashtable, which includes replacement algorithms and a consistency policy. When the hashtable has reached its maximum capacity, the evictor will evict items based on a replacement algorithm (e.g. LFU). The evictor is also responsible for invalidating cached items based on TTL (Time To Live) and invalidation reports from the PSC. The prefetching component is responsible for prefetching service response messages based on prefetching algorithm. The prefetching engine takes advantage of idle time and uses background threads to send prefetching requests to the service provider. On the client side, the prediction algorithm is based on utilizing BPEL files that describe the user workflows. On the server-side, the prediction algorithm is based on the prediction dependency relationship among services. The PSC analyzes the known relationships between the services and creates invalidation reports that are broadcasted to clients to ensure that no stale data is in their caches. The invalidation report is based on the invalidation dependency relationship. When the server receives a Write operation, it will check the invalidation dependency to decide which Read operations will be invalidated. The invalidation item will be service name and dependency parameter, and it will be added to the report. The invalidation report will be broadcasted to clients in a fixed period.
In order to evaluate the dual caching system, several experiments were performed. In the experiments Axis 1 was used as the Web Services middleware.
5.1 Measuring the Overhead of the Dual Caching The first experiments are used to determine the overhead and the gains of the dual caching approach. Using a CSC and a PSC (with infinite caching capacity) a sequence of different reads is performed. To measure the impact of the cache each experiment is performed with and without the cache.
800
Mean Latency (ms)
700
Orchestration Description
WSDL, WS-Policy
Transport
HTTP, SMTP, TCP/IP, FTP
200
90
10 0
80
70
60
50
40
30
20
10
1
with dual cache
without cache
Figure 7. Impact of Request Sizes Figure 7 shows the mean latency as the request message size is changed from 1k to 100k. This figure shows a linear increase of mean latency as a function of the request message size. To determine the impact of response sizes, a set of reads is performed that result in different response sizes. By changing the parameter, the response message changes from 1k to 100k. Again the experiment is performed with and without the cache. As shown in figure 8 the mean latency also increases linearly as a function of response message. To determine the gains of using the dual cache in connected mode a series of repeating reads is performed. The workload includes 10 identical READ operations, whose request message size is 1k and response message size is 50k. Since identical reads are executed it becomes possible to evaluate gains by using the cache. As before, the experiment is conducted with and without the cache.
OWL-S Profile
XML/SOAP, WS-Adressing
300
Request Message Size (kilobyte)
OWL-S Model
Messaging
400
0
WS-CDL BPEL, WSFL, XLANG,
500
100
The meta-data that is used on the PSC & CSC consists of three components, service description, client workflow description and connectivity description. The service description defines the cachability of a service and its relationship to other services (e.g. if a specific service call leads to an invalidation of cached data). To ensure interoperability OWL-S is used as a means to describe these relationships and the internal behaviour of the services in a platform independent way.
Choreography
600
Figure 6. Web Services Protocols
As shown in figure 9 the cache system reduces the latency dramatically since the costly sending of the SOAP messages is avoided. Note that by using the cache the service provider is subjected to a lesser load.
The client workflow is described using BPEL and enables the cache to predict future client requests. Given that BPEL is
791
800
Mean Latency (ms)
700
1.
Service requests are Poisson arrivals
2.
The service popularity follows a Zipf distribution.
3. Workloads are set based on the TPC-W Ecommerce benchmark: shopping, browsing, and ordering. (Table 1 shows the percentage of Read/Write operations in each workload.)
600 500 400 300 200
Table 1: Read/Write percentage in each workload
100
10 0
90
80
70
60
50
40
30
20
Workload Type 10
1
0
Response Message Size (kilobyte) w ith dual cache
w ithout cache
Figure 8. Impact of Response Size
After evaluating the dual cache with very basic workloads and paying no attention to the impact of cache-size the next experiments are designed to evaluate more realistic loads and the impact of limiting on the cache size of the CSC. The experiments test the impact of the CSC cache size with respect to mean latency and hit-ratio.
Read
Write
Browsing
95%
5%
Shopping
80%
20%
Ordering
50%
50%
350
Mean latency (ms)
300 250
BROWSING
200
SHOPPING 150
ORDERING
100 50
900
0 160
800
Latency (ms)
320
480
640
800
Cache size (kilobyte)
700 600 500
Figure 10. Mean Latency
400 300 200 0.8
100
0.7
0 2
3
4
5
6
7
8
9
0.6
10
Hit rartio
1
Request Number without dual cache
with dual cache
0.5
LRU
0.4
LFU
0.3
SIZE
0.2
Figure 9. Latency Reduction
0.1 0 160
In this experiment, the provider-side cache is configured to send metadata and invalidation reports. The workloads used are browsing, shopping and ordering and differ in the ratio of reads (cachable) and writes (not cachable) that result in invalidation of cached data.
320
480
640
800
Cache Size (kilobyte)
Figure 11. Cache Hit Ratio for Browsing
The resources on the provider are 100 text files that are read (read operations) or manipulated (write operations). The WS read and write operations are directly mapped to read/write operations of the files. The size of the files ranges from 2KB to 50 KB. There are 20 files are [2K, 10KB], 30 files are [10KB, 20 KB], 40 files are [20KB, 30KB] and 10 files are [30KB, 50KB].
0.6
Hit ratio
0.5 0.4
LRU
0.3
LFU 0.2
SIZE
0.1
Therefore, the average size of a response message E(S) = 160KB. There are 100 Read services to read each file, and 100 Write services to write to the each file. In the experiments, the parameters are set as following:
0 160
320
480
640
800
Cache Size( kilobyte)
Figure 12. Cache Hit Ratio for Shopping
792
bandwidth. Using a dual aching it becomes possible to handle loss of connectivity during the transmission of requests and the transmission of responses. An additional advantage of the dual caching is the reduction of latency and network load for workloads that contain significantly more read than writes.
0.25
Hit ratio
0.2
0.15
LRU LFU
0.1
SIZE
Future work will focus on:
0.05
0 160
320
480
640
800
•
Extending OWL to better model consumer activity since the current OWL & OWL-S do not provide mechanisms for describing the behavior of consumers. One possible approach would be the introduction of OWL-C (OWL-Consumer).
•
Extending OLW-S to enable mechanisms for describing how the services work internally.
•
The development of declarative models for predicting connectivity is another key issue in the caching for nomadic WS consumers. While statistics of past movements may serve as a good start it seem more promising to incorporate mechanisms of predicting the location, movement and consequently the available connectivity.
Cache Size (kilobyte)
Figure 13. Cache Hit Ratio for Ordering
Figure 10 shows the impact cache size has on mean latency if LRU is used. As expected the impact of the cache size is the greatest for workloads that have primarily reads. Consequently browsing (95 % reads) benefits more than shopping (80 % reads). Ordering which contains 50% reads benefits the least since the many writes invalidate cached reads. Figures 11,12 and 13 show the cache hit ratios that are obtained for different replacement strategies and cache sizes. LFU (least frequently used), LRU (least recently used) and SIZE (remove larges element in cache) perform similarly, indicating that the cache size is more important than the replacement strategy.
7. ACKNOWLEDGMENTS
5.2 Impact of Prefetching
We would like to acknowledge the continuous support of TRLabs Saskatoon and the NSERC LORNET project.
In the last experiment the impact of prefetching is evaluated. It is assumed that the CSC can predict with 100% accuracy the next consumer request. Again as expected the browsing with the 95% reads outperforms shopping (80% reads) which outperforms ordering (50% reads).
8. REFERENCES [1] Apache Software Foundation: http://www.apache.org/ [2] Visual Studio: http://msdn.microsoft.com/vstudio/
Mean Latency
[3] IBM Eclipse: http://www.eclipse.org/
Mean Latency (second)
4
[4] “Four Tenets of Service Orientation“
3.5 3 2.5
http://msdn.microsoft.com/msdnmag/issues/04/01/In digo/default.aspx
Normal Caching
2
[5] Chatarji, J. “Introduction to Service Oriented Architecture (SOA)”. http://w-ww.devshed.com/c/a/Web-
Prefetching
1.5 1 0.5
Services/Introduction-to-Service-OrientedArchitecture-SOA, 5 pages. 2004.
0
Browsing
Shopping
Ordering
[6] Roy W. Schulte and Yefim V. Natis Service Oriented Architecture, Gartner, 12 April 1996
Figure 14. Prefetching
[7] R. Friedman. Caching Web Services in Mobile Ad-Hoc Network. Proceedings of the second ACM international workshop on Principles of mobile computing. 2002. 90-96
6. Conclusions & Future Work This paper focuses on the challenges of enabling PDAs to host Web Services consumers and introduces a dual caching approach to overcome problems arising from temporarily loss of connectivity and fluctuations in
[8]
793
B. Terry, V. Ramasubramanian: “Caching XML Web Services for Mobility”: ACM Queue 1(1): 2003.
[9] V. Ramasubramanian and D. B. Terry. Caching of XML Web Services for Disconnected Operation. www.cs.cornell.edu/People/ramasv/ WebServiceCache/WebServiceCache(techfest).pdf
[12] Toshiro Takase, Michiaki Tatsubori: "Efficient Web Services Response Caching by Selecting Optimal Data Representation", 24th International Conference on Distributed Computing Systems (ICDCS), 03 24 - 03, 2004
[10] K. Devaram, D. Andresen: “SOAP Optimization via Client Side Caching”, Proceedings of the ICWS 2003.
[13] Hypertext Transfer Protocol – HTTP/1.1, RFC 2616:
[11] Takase, Toshiro and Nakamura, Yuichi and Neyama, Ryo and Eto, Hiroaki: “A Web Services Cache Architecture Based on XML Canonicalization”, Poster on Eleventh International World Wide Web Conference, 2002.
[14] W3C: Web Services http://www.w3.org/TR/ws-arch/
http://www.w3.org/Protocols/rfc2616/rfc2616.html
794
