Reducing User Perceived Latency in Mobile Processes

Reducing User Perceived Latency in Mobile Processes Daniel Schreiber, Erwin Aitenbichler Telecooperation TU Darmstadt Darmstadt, Germany {schreiber,erwin}@tk.informatik.tu-darmstadt.de

Andreas G¨ob CEC Darmstadt SAP Research Darmstadt, Germany [email protected]

Abstract—Employees are increasingly participating in business processes using mobile devices. Often, this is supported by a mobile web application, which accesses various web services in the back-end. The high latency of the mobile network (e.g., EDGE) is perceived by the user each time a web service is called, in addition to the time needed to invoke the service itself. This high latency may lead to low usability, low acceptance rate, and finally compromises the overall process quality. To reduce the latency perceived by the user, we present a caching architecture for web services and an adaptive prefetching algorithm. The key characteristics of our approach are the compatibility with major mobile browsers and the independence of the caching proxy from the frontend application and the back-end services. We evaluate our approach on realistic traces of web service calls in an IT service management scenario. The traces were generated from handling real incidents according to the ITIL (ISO 20000) processes. The results confirm that using our approach, the latency perceived by the user is reduced by 24%. Keywords-Web-based services; Mobile communication systems; Distributed applications; Buffering; Low-bandwidth operation; Human-centered computing;

I. I NTRODUCTION Many enterprises are organized along business processes. Every business activity in an enterprise belongs to a business process and every business process is associated with a highlevel enterprise goal, e.g., generating revenue or maintaining market leadership [1]. Thus, executing business processes fast and with high quality is key to business success. State of the art IT solutions supporting this form of organization rely on service-oriented architectures (SOA), mostly in the form of web services. Process steps that can be automated are realized by calling web services in the SOA back-end. However, many process steps still require human intervention. Therefore, processes need to be supported with interactive applications, i.e., applications with a user interface front-end and a SOA back-end. Following the trend towards the real-time enterprise, such applications are increasingly used in mobile scenarios [2], [3]. For example, IT service technicians need to access the enterprise SOA infrastructure to get incident and configuration information while they are performing on-site maintenance work.

Max M¨uhlh¨auser Telecooperation TU Darmstadt Darmstadt, Germany [email protected]

Supporting mobile process participation requires highly usable and highly available mobile applications, otherwise they will not be adopted by the employees, which will, e.g., keep reporting the data in bulk at the end of the work day from the convenience of their desktop. The main threats to availability and usability in mobile scenarios are the limited battery runtime of the mobile device and high user perceived latency. We calculate user perceived latency by comparing the time of the last action of the user (e.g., pressing a button in the UI) and the time the update of the UI happens with the results from the SOA back-end. For mobile applications with a SOA back-end, dealing with latency is crucial for their usability. The mobile application usually will call many different SOA back-end services to support the mobile process. If implemented in a naive way, the user perceives the invocation time of the service and the network time as latency, every time a service in the back-end is called. Furthermore, performing a high number of network requests consumes a lot of energy on the mobile device. However, designing the application to take latency issues and energy consideration into account, is expensive during development. The developer would have to carefully forsee where round trips between the user’s mobile browser and the back-end could be avoided. This is further complicated by the fact that different user’s use applications in different ways. Ideally, the adaptation should adapt to the individual user automatically [4]. In this paper, we address this problem and present a caching architecture for web services and an adaptive prefetching algorithm which reduces the user perceived latency in mobile processes. The key characteristics of our approach are compatibility with major mobile browsers and the independence of the caching proxy from the frontend application and the back-end services. Thus, existing services and off-the shelf mobile devices can be used without modification. The application developer does not have to make allowance for the peculiarities of mobile networks and the nature of the SOA services used, but can implement the application in a way solely reflecting the supported business process.

The contributions of this paper are the twofold. Firstly, we provide traces based on the ITIL processes and real data from the university IT department and quantitative results from experiments on this data. Evaluating our system with real data permits to assess the benefits of caching and prefetching in realistic scenarios for mobile processes. Secondly, we describe the architecture of our system that works with off-the-shelf mobile phone browsers, i.e., iPhone Safari and standard web services. Using realistic data allows us to evaluate the performance of the prefetching algorithm, which is a significant improvement compared to the experiments we performed previously [5], where only an artificial toy scenario was used. In addition, the implementation of piggybacking and caching has been improved compared to our previous work in [5], now parallelizing the piggybacking and the prediction process, which further increases the latency reduction. This novel implementation also allows to evaluate the effect of passing multiple prefetched items to the client, which was also not done in [5]. The rest of the paper is organized as follows. First, related work is discussed in section II. Next, we introduce the ITIL scenario in section III and our prefetching proxy in section IV. The evaluation for using our proxy in the ITIL scenario is described in section V. Finally, the paper is concluded in section VI. II. R ELATED W ORK Simple HTML user interfaces are provided by many industry business process management solutions, such as [6]. These could be directly used to participate in the process with any mobile browser. However, the HTML user interfaces are optimized towards a normal desktop workplace instead of to mobile devices and operation without network connection is not possible. The user perceived latency can be reduced by using a rich client hybrid architecture [7], where the client can cache results locally. This architecture also allows some degree of off-line operation. Using modern web technologies like AJAX, it is possible to implement this architecture in a web-based way [8]. In our implementation, we also adopt this approach. The client is implemented in JavaScript and connects to a server in the enterprise infrastructure. In our setting, the server is responsible for calling the necessary web services in the SOA back-end over the low-latency enterprise network. Caching results at the client can reduce the latency perceived by the user, as calls over the high-latency mobile network link are avoided and results are directly available from the cache. The impact of client-side caching on usability is shown by the findings in [9]. Using a client-side cache to reduce the latency perceived by the user is a well-known approach for non-mobile settings and has been described, e.g., in [10], [11] and [12]. These papers show how the

client-side cache can be filled in advance by predicting future user request and adding them to the cache using the network bandwidth in idle times. Ideally, the user will perceive no latency at all, as every request has already been fetched and added to the cache beforehand. The application developer would not have to design the application in a way to take user perceived latency into account. However, the implementation used in the non-mobile settings cannot be used in mobile settings. Continuously using the available bandwidth to prefill the client cache is infeasible in mobile settings, because this will severely hit the battery runtime of the mobile device. Prefetching and caching taking into account energy considerations have been described in [13]. However, the prefetching techniques described there assume a broadcast scenario, in which clients have to decide when to activate the network connection and actively prefetch data they observe from the broadcast channel. This is not applicable to mobile process participation, where a single client invokes several services in the back-end SOA infrastructure. Elbashir et al. propose a general approach for caching of web services for mobile devices in [14]. However, their approach requires that the application developer specifies the prefetching and caching rules in great detail, instead of easing the burden of the developer. A completely different approach for user interfaces to business processes are message-based approaches. They rely on exchanging documents between the user and the process. One such approach for mobile settings is described in [15]. The user can employ the messaging capabilities of the mobile device, e.g., e-mail and SMS, to interact with processes. However, nowadays mobile devices support full fledged web browsers, allowing to support interaction via graphical user interfaces. For process steps that require more than a short message as input, e.g., providing complete contact information of a customer, a modern web interface using AJAX features is much more usable. III. ITIL S CENARIO The benefits of caching and prefetching web service calls in mobile applications can only be evaluated with realistic workloads [16]. Unfortunately, it is difficult to get real web service call traces from business applications that are in production use. The underlying processes of an enterprise are considered to be a key to its competitive advantage, and the processes are thus kept secret. In addition, traces carry a lot of personal information about the involved entities. Even after anonymization, it is still possible to obtain sensitive statistical information from the data. When considering an IT scenario, e.g., it can easily be determined how often the product of a vendor A fails in comparison to a product by vendor B, or which user performs the most maloperations. To overcome this problem, we used data that was available to us to create our own traces. The Computer Operations

PASS Process Model

Mapping to Technical Services

Call Traces

...

Certified Engineer

Incident 100

Incident 1

1.. Receive appointment from OM -> Exchange 2. Check appointment -> Exchange 3. Confirm appointment -> Exchange 4. Receive work order -> OTRS 5. Check for on-site service or remote service 5a. on-site service: drive to customer 6. Check identity of CI -> CMDB 7. Execute work order Error case 1: Service cannot be established 7a. Return to DPL escalation -> OTRS, Exchange 10. Fill out material supply note for replacement and defective parts; send email to OM -> Exchange 11. Trigger logistic process 12. Document service provision 12a. Optionally send voice note -> Exchange 12b. Update ticket status -> OTRS 13. Send work documentation to OM -> OTRS 14. Process End

Call 1 URL: http://mundo.tk.informatik.tu-darmstadt.de/otrs/... Service: OTRSService Method: listTickets Arguments: userId:'erwin'

Call 16 URL: http://mundo.tk.informatik.tu-darmstadt.de/otrs/... Service: OTRSService Method: updateTicket Arguments: userId:'erwin',ticketId:'IC08570',key:'status'...

Figure 1: Steps to derive call traces starting from the ITIL standard process.

Group together with the Telecooperation Group at TU Darmstadt have expertise in the area of IT service and maintenance for several years. To obtain realistic call traces, we defined a business processes to handle IT service and maintenance incidents, and then played this process through with a number of selected real incidents. ITIL is the worldwide de-facto-standard for service management and contains broad and publicly available professional documentation on how to plan, deliver and support IT service features [17]. The procedure for generating the traces is shown in Figure 1. We started from the ITIL incident management process, which is part of the IT service management standard ISO 20000. A version of this process modeled in the process description language PASS (Parallel Activities Specification Scheme) was obtained from the company jCOM1 [6]. As back-end services we selected three well-known industry-strength products: OneCMDB (Configuration Management Database) [18], the Open Ticket Request System (OTRS) [19], and Microsoft Exchange 2007 [20]. The overall architecture of our test environment is shown in Figure 2. All three products offer Web Service interfaces. Next, the process was refined to incorporate the concrete web service invocations needed in each process step. This approach is basically the opposite to process mining, where an unknown process is discovered from a log of events, based on the ITIL processes, as described in [21]. To generate concrete call traces, we selected 100 incidents we have handled in the past and played them through based on the ITIL process on a prototype client. We have analyzed 1714 past incidents, documented in 6751 messages. 24% of these incidents were caused by maloperation. Such incidents do not trigger work orders for service personnel. Instead, the users are just informed about the correct use of the system. 60% of the incidents could be resolved using remote administration tools and 16% required on-site service. We were especially interested in the on-site service use-case.

Here, the certified engineer is working at the customer’s site and participates in the business process using his mobile device. We have selected 100 such on-site incidents for our evaluation. The traces are available for other researchers upon request 1 . IV. M UNDO PPP: P ROBABILISTIC P REFETCHING P ROXY Our system relies on a rich JavaScript client executed in the browser of the mobile device and the MundoPPP server that acts as gateway to the enterprise SOA back-end. Figure 2 shows an overview of this setup. This configuration is commonly found in enterprise software stacks, such as [8]. A. Rich Client The rich client application is entirely implemented in JavaScript. Thus, accessing the client is very simple: The user just points the mobile browser to a URL served by MundoPPP. Subsequent communication between the client and the back-end is then handled solely by AJAX requests. Implementing a rich client in JavaScript obviates the need for manual software installation on the client and makes updating and changing mobile applications extremely easy. Only a standard-conforming browser is required on the client, which is available on many off-the-shelf mobile devices. More information about how such a client can be implemented is given in [8] and [5]. Most important to the work described in this paper is that the client has a caching mechanism, which we refer to as client cache in the rest of this paper. In the most trivial implementation, the client cache stores all requests the client made and the corresponding responses. Requests are only sent over the mobile network if they cannot be answered from it. 1 please

contact one of the authors

hybrid client mobile application

mobile network link

enterprise network link

MundoPPP

SOA

JS client

OneCMDB AJAX

rich

Exchange

mobile browser

SOA back-end

OTRS

enterprise infrastructure

Figure 2: Hybrid client architecture for a mobile application accessing a SOA back-end. The rich client is implemented in JavaScript.

B. MundoPPP Server The mobile client does not access the enterprise SOA back-end directly. Instead, it uses MundoPPP as a proxy server. This has two reasons. First, only AJAX requests to the server the web application was loaded from are allowed because of the one origin policy. Consequently, the client would not be able to communicate with multiple different servers directly. Second, using a proxy allows to compress complex SOA messages returned by the back-end web services into a format more suitable for the client and the mobile network connection. MundoPPP acts as a dynamic web service invocation handler, i.e., the client sends a message to MundoPPP containing the WSDL location, the service name, the operation name, and JSON encoded parameters for an operation of a web service it wishes to execute. MundoPPP dynamically accesses the WSDL description, constructs a proper SOAP message, calls the web service, and translates the results into JSON format. MundoPPP can thus be used with any existing standard conforming web service in the SOA back-end. The JavaScript Object Notation (JSON) has been used instead of XML, because it is more compact and can be directly parsed by the JavaScript interpreter. C. Prefetching Our improvements to this basic architecture are twofold: Firstly, we use a prediction algorithm at the proxy to predict future requests of the client in an application independent way, and secondly we use a piggybacking mechanism to proactively inject the prefetched requests into the client cache. The prefetching algorithm is based on FxL. FxL was chosen as prediction algorithm, because it was shown to outperform several other prediction algorithms in a similar domain in terms of predicion accuracy and has a very

small footprint in terms of processing time and memory consumption [22]. In our previous experiments, we found that the time needed to make a prediction is negligible compared to the total user perceived latency [5]. The procedure for prediction can roughly be described as follows. MundoPPP matches the recent history of web service calls to the history of all observed web service calls, and uses the web service that most often succeeded the current history in the past as prediction for the future request. For example, if MundoPPP observes that the client performed the web service requests A and B, and in the past requests A and B where often followed by request C, then request C would be predicted. The predicted requests are executed in times between regular client requests and fill a cache on the server, the proxy cache. Subsequent requests from the client can then be handled much faster, as the response from the SOA back-end is already available in the proxy cache. For a more detailed explanation of FxL, we refer the reader to [22]. Several improvements to this basic approach have been implemented, e.g., the client informs MundoPPP of any requests that were retrieved from the cache between two server connections, to keep the history on the server in sync with the history of the client; a web service can be marked as not eligible for prefetching; and entries already present in the client cache are not sent to the client again. More details on the implementation of the prefetching algorithm can be found in [5]. D. Piggybacking The prefetching as described above leads to a much shorter roundtrip time and thus lower user perceived latency for the requests that can be answered from the proxy cache. However, the client still has to open a network connection and perform a request to the server. Each such roundtrip

comes with a constant overhead required for setting up the network connection, transmitting the HTTP header, etc. To further reduce the number of roundtrips from the client to MundoPPP, we devised a technique called piggybacking, where the proxy may send multiple responses to the client [5]. Using piggybacking, the proxy sends prefetched requests and their responses to the client together with the response to the client’s original request, i.e., the prefetched requests travel piggybacked with the original response as shown in Figure 4. In a mobile setting one cannot simply use the idle time of the client to fill the proxy cache with prefetched requests. Leaving the network connection open for long periods would consume too much energy from the battery of the mobile device. By using piggybacking, we increase the exploitation of the connection that has to be opened anyway due to the original request of the user. In our initial implementation described in [5], the response to the original request was sent together with the prefetched responses as one chunk of data. Furthermore, the prefetches were performed ad-hoc, i.e., while the connection to the client was open. This approach introduces a rather large prefetching overhead, because the response to the original request is only available after the prefetching has been completed (Figure 3). In the JavaScript client this behavior was implemented by attaching an event handler to the onreadystatechange event of the XMLHttpRequest object, which only accessed the response when the readyState reached 4, meaning completed. In the new implementation we introduced two improvements. The first improvement is the introduction of the proxy cache. This allows to perform prefetches on the server in advance. On the server we can use the idle time to prefill this cache, as battery runtime is not an issue for the server. Only prefetches that are readily available from the proxy cache are transmitted to the client during piggybacking. Second, the client now continuously parses the proxy response, to check whether a complete result is already available. If this is the case, the UI is updated immediately. This measure avoids the latency which would be introduced by delaying the UI update until all piggybacked prefetches have been received. Figure 4 shows a sequence diagram of the new behavior. As the same amount of data is sent from the server to the client, beside very few control characters, marking the boundaries between the results to the original request and the prefetched requests, the total duration of the network connection is not longer in this implementation than in the previous implementation of piggybacking. The latency overhead of prefetching is almost completely removed, and not noticeable compared to the normal variance of request times. The client cache and the proxy cache can be regarded as one single cache, which is implemented in a distributed way, i.e., eventually the client cache contains the same entries as

Figure 3: Sequential implementation of piggybacking

Figure 4: Prefetching is performed in idle periods on the poxy, the client continously parses the response text and the UI update is performed before the piggybacked results are added to the cache.

the proxy cache. However, due to the peculiarities of the mobile setting, the synchronization must be implemented carefully, taking energy considerations into account, e.g., by using piggybacking. V. E VALUATION We conducted a two-stage evaluation of our approach. First, we assessed how many additional cache hits predictive prefetching at the proxy could generate on the ITIL traces. Second, we measured how these additional cache hits affect the user perceived latency and online time of mobile applications supporting these processes. A. Experiment I - FxL Prediction on ITIL Traces For the first experiment, we used the web service traces generated by five service technicians in the ITIL scenario. Each service technician generated traces of web service

persistent cache

prefetchable invocations / upper bound (48.72)

50

20

10

prefetch multi

prefetch single

30 cache only

Hit Rate %

40

28.18

10.6 6.78

0.46

0

Figure 5: Comparison of prediction with pure caching and the impractical case of a persistent cache. The upper bound is given by the amount of prefetchable invocations. 35 30 Prediction Success Rate %

calls for 20 on-site incidents. We went through these web service calls of the ITIL traces in the same order a mobile application would, and counted the number of client cache hits h. We tested several different conditions for adding data to the client cache and emptying the client cache. We also counted the number of prefetched requests p sent to the client, as this corresponds to more network traffic and longer online times, which reduces battery runtime of the mobile device. As we just analyzed hit rates, it was not necessary to invoke the real web services in the back-end. Instead, requests were prefetched immediately to the client cache. We obtained values for h and p for the following five test cases. i) prefetchable: Several web service calls in the ITIL traces must not be prefetched, because they change state on the server, e.g., accepting a ticket. Such calls are often predictable, but they must be triggered by the user and cannot be called in advance. Whether a function is prefetchable or not must be annotated in the service interface description. An upper bound for the number of cache hits is thus given by putting all prefetchable web service calls into the cache from the beginning. ii) persistent-cache: In this case, all service calls were simply cached and the cache was never emptied. This results in a maximum number of cache hits, because our prediction algorithm only prefetches requests that have been observed before, and these would also be in the cache. However, such a setting is highly impractical as it would use stale data a lot of the time the cache is used. iii) cache-only: Here, the calls were simply cached and at the beginning of each incident, the cache was emptied to avoid stale data. Hence, the cache only helps if the same call is made more than once within the same incident. iv) predict-single: In this case, the cache was emptied at the beginning of each incident. Every time a request was made, is was added to the cache. Hence, repeating web service requests during the same incident were handled from the cache. Additionally, every time a web service call was sent to the server (as opposed to obtaining it from the cache), the FxL algorithm was used to predict a single other web service call. If any call was predicted with a confidence greater than a threshold, this predicted call was then also added to the cache. v) predict-multi: This case works similar to predictsingle, except that multiple predictions per request were used. All web service calls that were predicted by FxL with a confidence over a threshold t were added to the cache. A higher threshold t results in lower values for p and h. The results are shown in Figures 5 and 6. Figure 5 displays the average hit rates using all 100 incidents for the five cases described above. Figure 6 shows the average prediction success rates, relative to predictable, for the conditions predict-single, predict-multi, and cache-only. The hit rate is the number of cache hits h, divided by the number of web

predict-multi

25 20 15 10

predict-single

5 0

cache only -5 2

4

6

8

10

12

14

16

18

20

Incident (time)

Figure 6: The average prediction success rate “converges” after processing 5–10 incidents for both algorithms.

service calls made during one incident. To generate the graph we averaged the results of all five service technicians, each working on his own subset of 20 incidents. As one can see, there is a somewhat slow start, as the prediction algorithm has to learn about the application first, before it can provide good prefetching data. Figure 7 shows the correlation between the threshold t and the hit rate in the predict-multi case. It can easily be seen that lowering the parameter t increases the number of cache hits at the cost of more communication overhead, because more requests are prefetched. B. Experiment II - Effect on Latency To evaluate the effects on a real mobile device we selected one of the service technician traces and ran it with the mobile browser. For our measurements, we used the first three incidents of one service engineer as training data, i.e., just stored the respective requests in the prediction engine. We then played through the fourth incident of this service engineer with the real client on the mobile device. The incident we

4000 baseline proxy-p&c client-p&c

3500 3000

ms

2500 2000 1500 1000 500 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Figure 8: Comparison of user perceived latency under three different test conditions using an iPhone connected via EDGE.

25

Cache Hit Rate %

20

1.2 1

15

Hit Rate %

0.8

10

0.6 0.4

5

Communication Overhead

1.4

0.2

Comm. Overhead 0

0 1

0.8

0.6

0.4

0.2

0

Figure 7: The threshold parameter controls the FxL prediction algorithm. Lower thresholds lead to higher hit rates, but also add communication overhead. A hit rate of 15,2% is already attainable at 10% overhead.

used for testing consisted of 16 individual requests to the back-end. We measured the latency l perceived by the user and the total online time o by instrumenting the JavaScript code of the client. The latency was measured by comparing timestamps just before a web service request was made until the response was available. The online time was measured from the beginning of the request until the last prefetched response was available. We obtained measurements for l and o in three different test cases. i) baseline: In this case we did not use probabilistic prefetching at the proxy and no additional data was piggybacked to the proxy responses. As the incident does not contain duplicate requests, no requests could be answered from the client cache. ii) proxy prediction & cache: In this case we used a proxy cache which was proactively filled with predicted requests but did not send any piggybacked data to the client. Thus, some requests cause a much lower latency at the client. However, every request causes at least a minimum latency due to the overhead for connection setup.

iii) client piggybacking & cache: In this case we used a proxy cache like above but also sent the cache contents piggybacked to the client, where they proactively fill the client cache. In this setup the client may skip some server requests completely as they can be answered directly from the client cache. In the cases that used prediction, the threshold was set to t = 0.2, as this is a good tradeoff between additional cache hits and prefetching overhead, as can be seen in Figure 7. Apparatus: We used an iPhone (iPhone 3G, OS 3.1.3) as client device, accessing the MundoPPP server via an EDGE connection. MundoPPP was implemented as a Java servlet in Tomcat. As back-end services we used OneCMDB, OTRS, and Exchange. These services ran on a different computer in the local network. Thus, the setup exactly matched the one shown in Figure 2. Results: Figure 8 shows a comparison of the user perceived latency for all 16 requests of the incident in the three cases. Request #6 could be answered from the proxy cache, i.e., it was prefetched after one of the preceding requests. It has however not been piggybacked to the client cache, because the call to the web service in the back-end took so long that the result was not yet available in the proxy cache before request 6 was actually made. In contrast, request #9 could be piggybacked to the client. As a result, there is no user perceived latency for handling this request in the client piggybacking & cache condition. Figure 9 shows a comparison of the total values for l and o for all requests of the analyzed incident. The time spent in the SOA back-end for the requests that can be answered from the proxy cache accounts for approx. 20% of the total user perceived latency. Thus, introducing a proactively filled proxy cache alone leads to a 20% decrease in user perceived latency. Using piggybacking for transmitting the proxy cache contents to the client allowed to also reduce the latency, due to connection setup of requests piggybacked to the client. This reduced user perceived latency by a further 4%, yielding a total reduction of user

45

42.98 40.58

baseline proxy-p&c client-p&c

seconds

40 35

-19,6% 32.61 -24,2% 30.76

-18,6% 35.00

-24,5% 32.47

30 25 20 Latency

Online Time

Figure 9: Comparison of total user perceived latency and online time in the analyzed incident. The bars were scaled to start at 18.97 seconds, because this is the baseline back-end time.

perceived latency by 24%. Using the proactively filled proxy cache reduced the online time of the client by 19%. Here, piggybacking led to a further reduction of online time by 6%, totalling to 25% reduction of online time. VI. C ONCLUSION AND O UTLOOK We have shown how the user perceived latency for mobile SOA access can be reduced by employing an adaptive prefetching algorithm and caching. Experiments with realistic web service call traces showed that using a proxy cache proactively filled with requests predicted by the FxL algorithm can reduce the user perceived latency by 20%. Piggybacking additional results to the client cache leads to an overall reduction of user perceived latency by 24%. At the same time the online time can be reduced by 25%. Reduced online time directly corresponds to energy savings and longer battery runtime of the mobile device. Using the proposed approach, the decrease in user perceived latency comes without any additional tuning of the web services or the front-end application. The probabilistic prediction algorithm employed automatically adapts to the underlying application, thereby removing the burden from the developer to manually optimize for latency. In addition, it also adapts to the usage pattern of individual users. Even if the latency reduction for a particular setup cannot be exactly predicted, our approach should be adopted, as it comes without any drawbacks. The system decreases the latency in case of a successful prediction. If prediction is not successful, then the latency is not increased, because prefetching is done in a background thread that runs in parallel to the client application. The ITIL scenario traces are a valuable data set for further experiments. The web services used for the ITIL scenario are comparably well designed, i.e., the messages are relatively coarse-grained. There are however a number of SOA service implementations which use much more fine grained interfaces, down to providing get and set methods

for individual fields. Such systems would benefit even more from our prefetching and caching approach. The experiments we performed still leave open the question of how this reduction of user perceived latency translates to an increase in usability of the mobile application, and further into improvements of process quality. Following the ITIL process we could observe a significant quality improvement of our service. The process asserts more structured communication paths by a defined role distribution and by the regular examination of stored messages at certain points in the process. Solutions to problems can be found faster, because past solutions to similar problems by others can be reviewed. The quality assurance steps help to detect potential follow-up problems early and would have made some other incidents superfluous. Finally, it offers better scalability to more service agents and users. ACKNOWLEDGMENTS This work was partly supported by the Theseus Programme, funded by the German Federal Ministry of Economy and Technology under the promotional reference ’01MQ07012’.

R EFERENCES [1] W. van der Aalst, A. H. M. T. Hofstede, and M. Weske, “Business process management: A survey,” in Proc. of the 1st Intl. Conf. on Business Process Management, volume 2678 of LNCS. Springer-Verlag, 2003, pp. 1–12. [2] M. M¨uhlh¨auser and I. Gurevych, Eds., Ubiquitous Computing Technology for Real Time Enterprises. Information Science Reference, 2008. [3] R. Tergujeff, J. Haajanen, J. Leppanen, and S. Toivonen, “Mobile SOA: Service Orientation on Lightweight Mobile Devices,” in IEEE ICWS, 2007, pp. 1224–1225. [4] M. Hartmann and D. Schreiber, “Proactively adapting interfaces to individual users for mobile devices,” in Proc. of 5th Intl. Conf. on Adaptive Hypermedia and Adaptive Web-Based Systems. Springer, Jul. 2008, pp. (300–303). [5] A. G¨ob, D. Schreiber, L. Hamdi, E. Aitenbichler, and M. M¨uhlh¨auser, “Reducing user perceived latency with a middleware for mobile soa access,” Web Services, IEEE International Conference on, vol. 0, pp. 366–373, 2009. [6] jCOM1, “Welcome to the Future of BPM: S-BPM,” 2010. [Online]. Available: http://www.jcom1.com [7] V. Gruhn and A. K¨ohler, “Aligning software architectures of mobile applications on business requirements,” in WISM, 2006. [8] L. Hamdi, H. Wu, S. Dagtas, and A. Benharref, “Ajax for Mobility: MobileWeaver AJAX Framework,” in Proceedings of the WWW. ACM, 2008, pp. 1077–1078. [9] M. Pervil¨a and J. Kangasharju, “Performance of Ajax on Mobile Devices: A Snapshot of Current Progress,” in 2nd Intl. Workshop on Improved Mobile User Experience, 2008.

[10] V. N. Padmanabhan and J. C. Mogul, “Using Predictive Prefetching to Improve World Wide Web Latency,” ACM SIGCOMM Review, vol. 26, no. 3, pp. 22–36, 1996. [11] L. Fan, P. Cao, W. Lin, and Q. Jacobson, “Web Prefetching Between Low-Bandwidth Clients and Proxies: Potential and Performance,” in ACM SIGMETRICS, 1999, pp. 178–187. [12] A. N. Eden, B. W. Joh, and T. Mudge, “Web Latency Reduction via Client-Side Prefetching,” in IEEE ISPASS, 2000, pp. 193–200. [13] G. Cao, “Proactive Power-Aware Cache Management for Mobile Computing Systems,” IEEE Transactions on Computers, vol. 51, no. 6, pp. 608–621, 2002. [14] K. Elbashir and R. Deters, “Transparent Caching for Nomadic WS Clients,” in IEEE ICWS, 2005, pp. 177–184. [15] D. Chakraborty and H. Lei, “Pervasive enablement of business processes,” in Pervasive Computing and Communications, 2004. PerCom 2004. Proceedings of the Second IEEE Annual Conference on, 2004, pp. 87–97. [16] J. Dom`enech, A. Pont, J. Sahuquillo, and J. A. Gil, “A User-Focused Evaluation of Web Prefetching Algorithms,” Computer Comm., vol. 30, no. 10, pp. 2213–2224, 2007. [17] itil.org, “The portal for information regarding ITIL, ISO20000 and COBIT,” http://www.itil.org, 2010. [18] Lokomo Systems, “OneCMDB,” 2009. [Online]. Available: http://www.onecmdb.org [19] OTRS Team, “Open Ticket Request System,” 2009. [Online]. Available: http://otrs.org [20] Microsoft, “Exchange Web Services Architecture,” 2009. [Online]. Available: http://msdn.microsoft.com/en-us/library/ aa579369.aspx [21] D. R. Ferreira and M. M. da Silva, “Using process mining for ITIL assessment: a case study with incident management,” in Proceedings of the 13th Annual UKAIS Conference, Bournemouth University, apr 2008. [22] M. Hartmann and D. Schreiber, “Prediction Algorithms for User Actions,” in Proc. of Lernen Wissen Adaption, ABIS 2007, A. Hinneburg, Ed., Sep. 2007, pp. 349–354.