954 Ubiquitous Mobile Information and Collaboration Systems Achieving Web Service Continuity in Ubiquitous Mobile Networks: the SRR-WS Framework Christoph Dorn and Schahram Dustdar VitaLab, Distributed Systems Group, Institute of Information Systems, Technical University of Vienna, Vienna, Austria dorn|dustdar@infosys.tuwien.ac.at Abstract. In this paper, we will address two underlying problems of Web service continuity in mobile ubiquitous networks. On the one hand, our work presents a lightweight solution for connection interruption. On the other hand, we introduce a technique to switch between devices dur- ing service invocation. The Suspend-Relocate-Resume for Web Services (SRR-WS) Framework meets these challenges by allowing a device to disconnect in-between Web service invocation and response in order to retrieve the reply upon reconnection. Moreover, our proposed framework also enables on-demand transfer of service control from one device to an- other. Our first reference implementation demonstrates how Web service continuity can be achieved across devices as well as unreliable connec- tions. 1 Introduction Applying Web service technology in mobile ubiquitous environments enables in- teraction of heterogeneous resources through loose coupling as well as platform and context independence. Jørstad et al. present in [1] the advantage of ap- plying the Service-Oriented Architecture in mobile and ubiquitous networks in more detail. As mobile devices are getting more powerful and widespread, ac- cessing Web services with wireless devices is the next logical step. However, the dynamic nature of ubiquitous environments demands for adapted Web service technologies. Bandwidth and connectivity are the main factors besides comput- ing power, battery capacity, and input interfaces that restrict the deployment of Web service technology. In this paper, we focus on the issue of service continuity in a relaxed form. Instead of demanding anytime, anywhere available services, we argue that using the same service session on different devices from different places with possi- ble intermediary breaks is often sufficient. In many cases, a user needs not be persistently connected or does not desire it due to cost reasons. In Section 2, we present a motivating scenario and discuss problems and related factors that arise due to the dynamic nature of mobile networks. Section 3 discusses cur- rent approaches and solutions to these issues. Thereafter, Section 4 discusses UMICS'06 955 our proposal in detail. Subsequently, we present our results in Section 5. Finally, Section 6 describes future work, and Section 7 summarizes our findings. 2 Problem Statement First, we describe which components constitute a mobile ubiquitous environment concerning Web services. As presented in Fig.1, such an environment generally consists of wireless-enabled devices that communicate with each other and/or are connected to an access point. We also include a wired network in our setting having the role of an infrastructure of any kind or offering services. We justify this decision by making the assumption that mobile users venture between mobile and fixed network with and without their devices. However, possible scenarios in our environment need not rely on such an infrastructure (e.g., mobile ad- hoc collaboration). We have also identified four interaction patterns concerning service provider and service requestor location. 1. The wireless network hosts both requestor and provider. This usually occurs in (mobile) ad-hoc networks. However, infrastructure might exist that aids interaction between peers. 2. The requestor is mobile whereas the provider is situated in the wired part. This is probably the most common setting, opening up wired services also to nomadic users. Furthermore, current tool support for mobile devices is restricted to Web service client development. Therefore, our work focuses primarily on this interaction pattern. 3. The requestor is located in the wired part and invokes a service on a mobile device. This can be used for push services or tracking purposes. 4. Conventional Web service invocation happens as both requestor and provider are located on the infrastructure network. So far, Web service clients access services from static machines and are bound to these for the duration of service invocation. However, in a mobile environment we cannot expect a device or associated user to remain within transmission range for the full length of a possibly long lasting service interaction. Several strategies are available to handle this problem. – First, the user can choose to switch to another device that is able to remain connected. – The user selects an equivalent service that is within reach. – After the initial service is available again, the user reconnects and starts from the beginning of the service session. – The user delegates the service request to an intermediary such as agent or proxy in advance. Once reconnected, he/she collects the service response from that intermediary. Clearly, the first three approaches are unsuitable, as in each case the user has to reinvoke the service. Besides, to repeat all previous steps of service invocation requires time and retransmission of data. This not only increases the load on the 956 Ubiquitous Mobile Information and Collaboration Systems P 3 R 4 R 2 P R, P 1 P R, P Fig. 1. Ubiquitous Mobile Environment: consisting of wireless and wired connections. R signifies a Web service requestor, while P denotes a Web service provider. Note that provider and requestor can reside on the same node. (1) to (4) indicates the outlined four interaction patterns. wireless network but also results in the user being charged more as his/her data transfer volume increases1 . Moreover, in the second case an additional overhead occurs as we need time and resources to find a substitute service. Furthermore, some services might not be exchangeable at all such as personal calendar, doc- ument management or infrastructure centric services in general. Our work falls into the last category together with a number of related papers. Section 3 lists existing work and points out the differences to our approach. The following scenario presents the above-introduced issues and sets our pro- posed framework in a real world environment. Mike is a senior manager at ACME. As he is rather busy, he starts working already at home after getting up in the morning. He connects to his company’s network from his home computer. All services and resources of ACME are acces- sible by means of Web services. He requests to get an overview of all currently running projects. As this usually takes a while, Mike decides not to wait for the results at home. A conventional Web service would require him to collect the results from his home PC, but luckily ACME provides the SRR-WS proxy and SRR-WS enabled clients. Usually, he would access the outcome from work, but as Mike is on a business trip to London, he intends to use some spare time on the airport to check up on the results. Just before leaving the house he requests information on the current traffic situation in London. Then, he turns off his PC and heads for the car. While driving his car, Mike usually refrains from using 1 Here, we assume that the mobile network provider charges by the amount of data transferred neglecting the possibility of a flat rate UMICS'06 957 his PDA as he considers this too dangerous. After having checked in at the air- port, he connects his PDA to the wireless LAN in the business lounge. There he continues the web services he had interrupted by leaving his home. This is made possible as the SRR-WS framework allows to pickup a service session where it was suspended. The project report is still outstanding while the traffic report has arrived. This service, while being external to ACME, can still be access through the SRR-WS proxy. Once at his partner’s office in London, Mike connects his Laptop and retrieves the project results. The scenario highlights the main contributions of our framework. – Transparency: As there is no need to adapt the service provider, it remains completely unaware of the SRR-WS framework. – Service independence: Any service client that adheres to the standards can be suspended and resumed as well as relocated. – Light-weight approach: We require no middleware or agent platform and no proprietary standards are involved. The required infrastructure is limited to the use of the slim SRR-WS framework. – Continuity across time, space, and devices: Services can be invoked in one place and continued after some time in another place. Furthermore, the uti- lized devices need not be the same for suspending and resuming. – Fixed and mobile applicability: The presented framework is not restricted to mobile networks but can also be utilized in wireline networks. – Strategies for session keep alive: Instead of simply caching a response, dif- ferent strategies can be employed to enable session resumption at a later stage. Figure 2 visualizes the underlying ubiquitous environment depicting used devices and network topology. 3 Related Work Work in this section is focused on the aspect of service continuity and the above- introduced sub problems of service disconnection and service control handover between devices. Jørstad et al. [2] analyse service continuity in mobile services. They propose a service continuity layer consisting of a monitor, handover manager, service composition module, interoperability evaluator, and I/O redirector. Yet, their work remains at that level and lacks specific details concerning architecture and implementation. Furthermore, their approach does not have the notion of service suspension. Another major difference lies in the task of the handover manager. This component is concerned with switching between different means of transport rather than devices. Finally, their service continuity layer focuses at providing services, whereas our technique requires no changes to the invoked services. Several agent frameworks and middleware have been designed to facilitate the use of Web services on mobile devices. Below, we introduce approaches which 958 Ubiquitous Mobile Information and Collaboration Systems PDA Airport Laptop London Home PC ACME SRR-WS Proxy Traffic Service Services Fig. 2. Scenario Environment: presents a simplyfied version of a real world ubiquitous environment including the various devices employed, the SRR-WS framework and the example Web services. focus on agents and/or proxies invoking Web services on behalf of a mobile client. Thus, they enable the client to go offline during the service execution. Yu and Zhang [3] introduce a mobility system based on mobile agents to provide service continuity across networks. Yet, the need for an agent platform narrows widespread applicability. Furthermore, handover between devices is not explicitly given. In [4], a client-proxy-multiple server model is designed where broker agents accept requests from mobile clients. These can resort to a knowledge base on the capabilities of service agents to perform the required task. Service agents belong to a specific problem domain and act as a wrapper to services described through a DAML+OIL ontology. The actual computation is done on the agent platform, on execution platforms or if required and possible on the client itself. Agent- deputies handle disconnections. Zahreddine and Mahmoud [5] and Maamar et al. [6] present similar agent-based frameworks. Okuda et al. [7] explicitly address continuous service access by means of agents. They adopt the same definition regarding service continuity as we do, namely suspending services, and resuming at a later point in time. Moreover, they also support continuing from a different device. However, their work is focused on multimedia web content that is adapted to different device capabilities and not on invocation of Web services. Hence, their technique varies considerably compared to our approach. UMICS'06 959 At this point, we can highlight several shortcomings that the presented work hitherto has in common. Agent networks in general lack widespread acceptance due to the need of a respective platform. Furthermore, Web service continuity across devices is only supported implicitly and service interruption not at all. These two aspects are the central focus of Satyanarayanan et al. [8]. However, their approach goes beyond the scope of our work as the presented mechanisms transfer the whole state of the device using a distributed file system. We claim that this technique is too heavy weight and does not take into account unfinished service sessions. Work on handover is primarily concerned with switching between different kinds of networks (eg. WLAN to GRPS or UMTS). As handover takes place at the transport layer to provide continuous connections for synchronous com- munication, interruptions constitute an undesirable state. However, this is less of a problem in the case of Web services where asynchronous communication is prevailing. Hence, our approach currently excludes such transport mechanisms but they pose a promising field for future extensions. For example, Calvagna and Modica [9] propose user-centric policies for vertical handover in order to reduce costs for the individual user. Bellavista et al. [10] present a middleware architecture for context aware service deployment and handoff management. Pilioura et al. [11] analyse Web service scenarios for mobile commerce. In the case of providing stable Web services to mobile devices, they propose a proxy architecture to invoke services on behalf of a client. Although their approach is similar to ours, we point out that the proxy needs to create a stub for every un- known request as their service requestor is assumed to be Web service unaware. This results in much more overhead than simply forwarding a service invoca- tion message. Furthermore, no explicit mechanism to switch between devices is included. To the best of our knowledge, so far no research effort has been put into de- signing a generic pause-resume mechanism for Web service invocation. Services themselves can be designed to allow for breaks by implementing long timeouts or resending messages, but this is not a transparent approach. Another possi- bility would be to utilize SOAP over SMTP, which intrinsically includes delays. However, this would require SMTP servers running on the mobile clients, or a SMTP push infrastructure. Moreover, this technique is specific to the underlying transport protocol and outside the scope of the Web service interaction layer. Besides, an SMTP server does not feature any keep-alive strategies and session relocation facilities as the SRR-WS proxy provides. This pause-resume mechanism mentioned above holds much of the asyn- chronous notion that is usually associated with Message-Oriented Middleware (MOM). Such systems, however, are usually heavy-weight and restrict clients to connect to services available only within each such MOM. Though, our generic technique is open to any Web service client. Following papers do not directly address service continuity issues as such, but provide techniques that reduce the need for service suspension and relocation. Yet, our framework is likely to incorporate these approaches at a later stage. 960 Ubiquitous Mobile Information and Collaboration Systems Sen et al. [12] propose to tackle connectivity issues by invoking the Web ser- vice that is the most likely to remain available for the duration of the interaction process. A reasoner accessing a knowledge base—that contains motion informa- tion on participating service provider nodes—predicts the node’s locality at the required place at the required time. Similarly, Doulkeridis et al. [13] introduce the notion of a context-aware ser- vice directory that includes temporal information. They argue, that context related data would enable prediction of the period a certain service remains available. Friedman [14] who proposes to cache the actual Web services within an ad-hoc network brings up another option. Upon partitions or combinations of network sections, caching proxies are either spawned or combined. In this environment only those services can be rendered ubiquitous that can be transferred or copied as a whole between nodes. 4 The Suspend-Relocate-Resume for Web Services (SRR-WS) Framework Our approach focuses on service continuity at the client side by introducing the Suspend-Relocate-Resume for Web Services (SRR-WS) framework. It enables to suspend a service, optionally relocate the client’s session data, and to continue where the client has paused its interaction. As shown in the section on related work, no generic mechanism for resuming has been proposed so far. Thus, we cannot assume that Web service providers feature suspend or resume capabilities. Hence, the first version of our framework has the requirement that the Web service provider side should be left unaffected and thus the client side has to take provisions for service interruption. The SRR-WS design consists of a proxy—that we kept as generic as possible—and client side session restorement facilities. Figure 3 gives a general overview. The SRR-WS Proxy is composed of three components: the actual proxy (P- module) that forwards SOAP messages over HTTP to the ultimate receiver, the suspend and resume module (SR-module) as well as the session relocation mod- ule (R-module). The internal architecture of the whole proxy is given in Figure 4. The latter two modules are designed as Web services. The SR-module allows the client to explicitly request a connection interruption for going offline or shutting down, while enabling it to resume the session once it reports back. We define a session as a combination of client-state information and pending invocation requests. The R-Module permits a client to transfer the current session onto another device for later continuation. This feature is central to achieving service continuity across devices. The SR and R modules operate independently of each other. Thus, suspending and resuming can be executed on the same device, while session relocation can also occur in case no invocation reply is pending. Yet, the combined functionality enables virtually “anytime” relocation. The SR functionality is most useful for stateful services that require some identifying data to be kept throughout the session. Nevertheless, stateless ser- UMICS'06 961 Fig. 3. The SRR-WS Framework consists of a generic Web service proxy with addi- tional capabilities regarding caching and session relocation as well as facilities at the client to enable session suspension and continuation. vices can also profit from the framework, as asynchronous responses are stored during a client’s offline period. This also holds true for services, which exhibit high invocation costs or long execution time. Fig. 4. The SRR-WS-Proxy consists of a SOAP proxy and Web service interfaces for suspending and resuming a process as well as transferring the client’s session data onto another device. What remains to be defined is how to keep a session alive. As we argue that the proxy should remain ignorant of the semantics of any requests, we propose that the client should know how to keep a session running. In invoking the SR interface, the client defines how this should be done. Below, we list possible strategies that we identified as suitable. Note that different strategies can be used at different points in the interaction process. 962 Ubiquitous Mobile Information and Collaboration Systems None the client knows that at this point, the session cannot be kept alive by the proxy itself. Thus, the proxy won’t cache the Web service response. Wait the client indicates that the proxy should just wait for it to report back from being off-line or down and then forward the stored Web service re- sponse. This strategy is applied if no timeout is expected to occur. Replay the proxy should replay the last SOAP request at specific intervals. Always the latest response is kept. Replay works the same way as a web browser’s reload functionality behaves: retrieving the most up to-date-information while keeping a possible session alive. Custom the client provides a custom message which the proxy should forward at the given intervals. As in the previous case, the Proxy stores the latest reply from the Web service. The Custom strategy behaves just as the Replay strategy, while not sending the last message but a different one. The latter three strategies include an interval within which the client expects to report back. Yet, the proxy can choose to reduce this value, if its “offline time span” is less. In such a case, the proxy notifies the client about the new valid deadline in the immediate reply message. Yet, to avoid side effects, the client needs to know how the Web service will behave for each of these strategies. However, we argue, the more complex a service is, the better the client needs to know it already without using the SRR-WS framework. Session relocation is kept rather simple. The client describes relevant session data as an XML document and transfers it to the relocation module on the proxy. It also provides a deadline until itself or another client intends to retrieve the data. The relocation session data are stored on the SRR-WS proxy, which returns an identifier for later recovery. Retrieval happens exactly the opposite way. As the client provides the session identifier, the proxy returns the XML document. On the client side, the framework consists of an additional layer between Web service proxy and transport engine to enhance the header with SRR-WS identifi- cation information. Specifically, we use the MessageId of the WS-Addressing [15] header to enable this in a standardized way. The proxy processes this informa- tion to establish later which SOAP request should be suspended. This additional SOAP header block is kept even as the request is forwarded to the actual desti- nation as WS-Addressing might be used at the ultimate receiver’s site. Figure 5 visualizes this concept on the client device. The displayed components are the client application, WS-Addressing (for providing the necessary correlation head- ers), the SRR Client Framework (provides functionality for handling suspend and resume as well as relocate requests), WS Client Stub and SRR Client Stub to transform methods into SOAP messages (these are automatically created by an WSDL parser), and finally the HTTP Engine (responsible for wrapping the SOAP message in a HTTP POST request and subsequent transmission to the proxy). UMICS'06 963 Fig. 5. At the client side the SRR-WS Framework consists of an additional layer to introduce process related session identifier and a stub for accessing the SRR-WS Web service interfaces. 5 Implementation and Results We implemented our framework using SOAP over HTTP as it is most widely applied. Besides, using SMTP we would not be able to point out the impact our framework has on Web service interaction, as an SMTP server can, in some way, be regarded as an implicit SRR-WS-Proxy. Furthermore, WS-Addressing was our choice of message identification mechanism as it provides this functionality in a reasonably comfortable way, thus no need for another standard or proprietary SOAP header. WS-Addressing is supported by Microsofts .NET Framework 2003 Web Service Extensions 2.02 which is also available for PocketPC by means of the OpenNETCF [16] framework. One problem that had to be tackled in using SOAP over HTTP in conjunction with WS-Addressing results from the fact that once we have invoked a request and are waiting for a reply, we have to abort it to suspend. Thus, to receive the reply from the SRR framework upon resuming, we need to invoke the same request again but this time with a new WS- Addressing MessageId. In order for the SRR framework to know, which reinvoked requests desires what stored reply, MessageId mapping is done. This is explained in further detail below when discussing the Suspend-Resume module. 5.1 The Proxy Module The HTTP SOAP proxy has not been written from scratch but the free Men- talis.org proxy [17] has been adapted to fit our needs. More precisely: we made the proxy SOAP aware, thus processing SOAP requests in a way to enable pos- sible suspend and resume action. For regular HTTP requests, the proxy acts as usual. Once the proxy receives a SOAP request, it checks whether this request 2 Microsofts Web Service Extensions 3.0 are available as well but incompatible to the OpenNETCF framework. 964 Ubiquitous Mobile Information and Collaboration Systems needs to be forwarded to the ultimate receiver (a new request) or was sent to re- trieve a stored reply (a reinvoked request). In the former case, the proxy connects to the given destination and waits for the reply. Once the complete response is received it checks whether the corresponding client has suspended (subsequently storing the message) or not (forwarding the reply the the client). In case of a reinvoked request, the proxy retrieves the stored response and returns it without connecting to the actual destination. Errors during client-proxy communication have no effect on the proxy’s state. Initial requests or invocation of the proxy’s suspend or relocate service are sim- ply ignored. If an error happens during session resumption or session takeover, related data is not lost but kept for a new retrieval attempt. 5.2 The Suspend-Resume Module and KeepAlive-Strategy The SR-module is accessible via two Web service methods for suspending and resuming. To suspend one or several request, the client needs to provide a KeepAlive-Strategy for every single one. Such a strategy corresponds to the types introduced above, namely: None, Wait, Replay and Custom. Besides iden- tifying which request is to be suspended (by means of the MessageId), it further includes details on how long the response should be stored (at most), the max- imum interval between resuming and actually reinvoking the request, and the custom message (if required), as well as the resend interval where appropriate. For resuming one or more requests, the client submits the mapping between original request MessageId and the one that is going to be used for reinvoking. Hence, the SR module, repectively the SOAP proxy, can distinguish between new and resumed SOAP requests. The client also includes the proxy identifier which is needed in case a network of distributed proxies is used. 5.3 The Relocate Module The R-module allows session data in the form of a serialized XML document to be stored for a certain amount of time. Upon submission of a session document, a unique identifier is generated and returned to the client for future retrieval. The same client or another one that possesses the identifier, can use it to take-over the corresponding session information. The transfer of session information can also be described as pushing and pulling a session to the SRR-WS framework. We left this module intentionally simple for demonstration purpose and leave it up to the client application to transfer the session identifier to another client instance in case of relocation. The session description in XML is left to the client and the framework provides no support, as we believe session data will vary significantly between applications. 5.4 The Test Run The testing Web service was implemented as a Google Web service [18] re- lay that transfers requests from document to RPC SOAP style. However, for UMICS'06 965 simplicity reasons, only the spelling suggestion method is available. The ser- vice waits for ten seconds to simulate a longer lasting interaction and returns the Google result3 marked with a timestamp. The proxy part of the WRR-WS framework runs on Windows XP Professional on the Internet Information Server (IIS). In our test bed we had a Pentium III Laptop as proxy host connected via LAN to another Windows XP machine, hosting the Google relay Web service. Our demonstrations client was implemented on an iPAQ 2210 running Windows Mobile 2003 and accessed the SRR-WS framework proxy by means of WLAN 802.11b in adhoc-mode. Our tests showed that as expected, several invocation requests could be issued, then these requests were suspended, the session pushed to the SRR-WS proxy and the client closed before the PDA was switched off. Within the suspend timeout, we restarted the client applications, retrieved the session data, then resumed the session and received all stored invocation replies. For the four keep alive strategies, we experienced behavior as expected. – Providing the None strategy, the proxy aborted the connection to the test service or—if already available—deleted the reply. – Requesting the Wait strategy, the timestamp in the service reply amounted for about ten seconds more than the time of initial service invocation. – Demanding the Replay strategy for every 20 seconds, the timestamp in the service reply ranged between 10 and 20 seconds less than the point in time of service resumption. – For the Custom strategy having the same values as the Replay strategy, we experienced also the same timestamp values. 5.5 Evaluation Currently, we cannot make extensive statements about the performance of our framework as message overhead heavily depends on the applied keep-alive strat- egy. Nevertheless, in the following list we give an indication where to expect the most improvements and which strategies need closer attention. – The None strategy is equivalent to experiencing a service interruption with- out the SRR-WS framework with an additional message to notify the SRR- WS proxy neither to store nor to wait for a reply. – Wait involves one message to inform the proxy to store the reply and another one to resume the invocation. – The amount of messages for Replay and Custom cannot be determined with- out knowledge of the exact strategy parameters. At a minimum, we have two messages (as this case includes the previous one) and at least another one, if the message is resent once only. Otherwise we have the client’s offline pe- riod divided by the strategy’s replay interval. Thus the worst case scenario happens if the client does not report back within the proxies internal “offline time span”. This holds true for both Replay and Custom. 3 In case a google key is not available, use “test” as the key, and only the timestamp will be returned. 966 Ubiquitous Mobile Information and Collaboration Systems While analysing the expected message overhead, this amount has to be put in contrast with the number of messages needed in case of a new session start. Concerning scalability, the proxy certainly constitutes a bottleneck. Yet, we argue that a network of distributed SRR-WS proxies can solve this problem. A client can still use a different proxy (ProxyB) for resumption than used for suspending (ProxyA). This is achieved as the client submits the proxy’s identi- fier (as mentioned above). All ProxyB needs to do is forward the request to the initial proxy (ProxyA), which returns the stored reply. This is in turn relayed to the client. Then ProxyB handles all subsequent traffic. Thus, no replication of state information occurs as ProxyA stores the initial reply, and ProxyB merely fetches that information upon the client’s request. In such a federation, various hosts such as companies or universities (e.g., ACME in our scenario), network operators (e.g., WLAN hotspot providers), or individuals (e.g., Mike might de- cide to have one at home) provide proxies. Unfortunately, we lacked time to implement and test this feature. The need for suspending a service explicitly might seem a like an unrealistic assumption in an adhoc network. However, we argue that this is less of a concern as the framework is not specially designed for an adhoc network but rather an ubiquitous one. Furthermore, users explicitly switch on or off their devices and do so when changing to another device. Moreover, context information can be used to anticipate potential disconnections. Yet, this is outside the scope of our paper. 6 Future Work Future work will consist on the one hand of improving the demonstration im- plementation. At the moment a tight integration between client application and client-side framework is required. We plan to aid the developer in providing an automatic wrapper around Web services and a less tightly coupled SRR frame- work. For example, BPEL processes enhanced with business rules as proposed by Rosenberg and Dustdar [19] define timeouts and session constraints and thus enable automatic selection of appropriate keep-alive strategies and correspond- ing SOAP messages. Furthermore, direct transfer of session data between clients would be an improvement we intend to implement. On the other hand, broaden- ing the applicability of the SRR-WS framework concerning transport protocols, keep alive strategies, and security is another issue. Combining SOAP transport protocols such as HTTP request and SMTP reply (with mail push) might prove interesting to follow-up. In addition, security capabilities that have been left out for the moment, need consideration and integration. Furthermore, our case studies will also show if the current keep alive strategies are generic but also specific enough for widespread use. The further step would consist of enabling Web services themselves to accept suspend and resume requests. This would al- low a better integration of session interruption and would require no additional infrastructure such as the SRR-WS framework. However, for generic use this would need to be the subject of a new Web service standard. UMICS'06 967 7 Conclusion In this paper, we have discussed service continuity in mobile ubiquitous envi- ronments and presented a motivating scenario. Having listed current approaches to the service disconnection and relocation issues, we introduced our solution. The Suspend-Relocate-Resume for Web Services framework (SRR-WS) acts as a generic proxy for requests and caches invocation responses while a client remains off-line. Furthermore, it enables to start an invocation request on one machine and continue on a client located on another one. Thus, we achieve service conti- nuity across space, time, and devices. Besides discussing our framework, we have presented a reference implementation demonstrating the benefits in a wireless network. Our main contributions are a lightweight framework that acts trans- parently to service providers while remaining unaware of the actual service invo- cation content. Moreover, the SRR-WS framework can be used in wireless and wireline environments and introduces strategies to keep service sessions during client’s offline period alive. We concluded that our framework remains promising, but needs to be employed in a real world environment for further improvement. Acknowledgment Part of this work was supported by the Austrian Science Fund (FWF) project OMNIS. References 1. Jørstad, I., Dustdar, S., van Do, T.: Service-oriented architectures and mobile services. In: 3rd International Workshop on Ubiquitous Mobile Information and collaboration Systems (UMICS), co-located with CAiSE 2005. (2005) 2. Jørstad, I., van Do, T., Dustdar, S.: A service continuity layer for mobile services. In: IEEE Wireless Communications and Networking Conference. (2005) 2300–2305 Volume 4 3. Yu, Y., Zhang, P.: Service mobility in mobile network. In: International Conference on Communication Technology, ICCT 2003. (2003) 1698–1701 4. Chakraborty, D., Perich, F., Joshi, A., Finin, T., Yesha, Y.: Middleware for mobile information access. In: 5th International Workshop on Mobility in Databases and Distributed Systems (MDDS 2002). (2002) 5. Zahreddine, W., Mahmoud, Q.: An agent-based approach to composite mobile web services. In: 19th International Conference on Advanced Information Networking and Applications, 2005. AINA. (2005) 189–192 6. Maamar, Z., Sheng, Q.Z., Benatallah, B.: On composite web services provisioning in an environment of fixed and mobile computing resources. Information Technol- ogy and Management 5 (2004) 251–270 7. Okuda, T., Takano, M., Tajima, K., Shimojo, S., Yamaguchi, S., Miyahara, H.: Realizing continuous and transparent service using agents. In: IEEE Pacific Rim Conference on Communications, Computers and signal Processing, 2001. PACRIM. 2001. (2001) 736–739 968 Ubiquitous Mobile Information and Collaboration Systems 8. Satyanarayanan, M., Kozuch, M., Helfrich, C., O’Hallaron, D.: Towards seamless mobility on pervasive hardware. Pervasive and Mobile Computing 1 (2005) 157– 189 9. Calvagna, A., Modica, G.D.: A user-centric analysis of vertical handovers. In: WMASH ’04: Proceedings of the 2nd ACM international workshop on Wireless mobile applications and services on WLAN hotspots, New York, NY, USA, ACM Press (2004) 137–146 10. Bellavista, P., Cinque, M., Cotroneo, D., Foschini, L.: Integrated support for hand- off management and context awareness in heterogeneous wireless networks. In: MPAC ’05: Proceedings of the 3rd international workshop on Middleware for per- vasive and ad-hoc computing, New York, NY, USA, ACM Press (2005) 1–8 11. Pilioura, T., Tsalgatidou, A., Hadjiefthymiades, S.: Scenarios of using web services in m-commerce. SIGecom Exch. 3(4) (2003) 28–36 12. Sen, R., Handorean, R., Roman, G.C., Hackmann, G.: Knowledge-driven inter- actions with services across ad hoc networks. In: ICSOC ’04: Proceedings of the 2nd international conference on Service oriented computing, New York, NY, USA, ACM Press (2004) 222–231 13. C.Doulkeridis, Valavanis, E., Vazirgiannis, M.: Towards a context-aware service directory. In: 29th International Conference on Very Large Data Bases (VLDB 2003). (2003) 14. Friedman, R.: Caching web services in mobile ad-hoc networks: opportunities and challenges. In: POMC ’02: Proceedings of the second ACM international workshop on Principles of mobile computing, New York, NY, USA, ACM Press (2002) 90–96 15. Box, D., Christensen, E., Cubera, F., Ferguson, D., Frey, J., Kaler, C., Langworthy, D., Leymann, F., Lovering, B., Lucco, S., Millet, S., Mukhi, N., Nottingham, M., Orchard, D., andE. Sindambiwe, J.S., Storey, T., Weerawarana, S., Winkler, S.: Web Service Addressing (WS-Addressing). http://www.w3.org/Submission/ws- addressing/ (2004) 16. OpenNETCF.org: OpenNETCF Website (2005) 17. Mentalis.org: Mentalis.org Proxy Website (2005) 18. Google: Google web service api (2005) 19. Rosenberg, F., Dustdar, S.: Business Rules Integration in BPEL - A Service- Oriented Approach. In: 7th IEEE International Conference on E-Commerce Tech- nology, CEC. (2005) 476–479