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 during 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 another. Our first reference implementation demonstrates how Web service continuity can be achieved across devices as well as unreliable connections.
Applying Web service technology in mobile ubiquitous environments enables
interaction of heterogeneous resources through loose coupling as well as platform
and context independence. Jørstad et al. present in [
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 possible 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 current approaches and solutions to these issues. Thereafter, Section 4 discusses 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
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 adhoc 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 R, P
P 1
R
2 3
R, P 4
R
P
P 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, document 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 proposed 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 accessible 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 his PDA as he considers this too dangerous. After having checked in at the airport, 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 utilized 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, different strategies can be employed to enable session resumption at a later stage. Work in this section is focused on the aspect of service continuity and the aboveintroduced sub problems of service disconnection and service control handover between devices.
Jørstad et al. [
Several agent frameworks and middleware have been designed to facilitate the use of Web services on mobile devices. Below, we introduce approaches which Home PC
PDA Airport
Laptop London ACME Services
SRR-WS Proxy
Traffic Service 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 [
In [
Okuda et al. [
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. [
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
communication, 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 [
Pilioura et al. [
To the best of our knowledge, so far no research effort has been put into designing 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 possibility 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 asynchronous 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.
Sen et al. [
Similarly, Doulkeridis et al. [
Friedman [
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 (Pmodule) that forwards SOAP messages over HTTP to the ultimate receiver, the suspend and resume module (SR-module) as well as the session relocation module (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 services 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.
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. 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 response. 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
identification information. Specifically, we use the MessageId of the WS-Addressing [
OpenNETCF framework. needs to be forwarded to the ultimate receiver (a new request) or was sent to retrieve 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 simply 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 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 identifying 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 maximum 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 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 testing Web service was implemented as a Google Web service [
Currently, we cannot make extensive statements about the performance of our framework as message overhead heavily depends on the applied keep-alive strategy. 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 without the SRR-WS framework with an additional message to notify the SRRWS 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 without 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 period 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. 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 identifier (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 decide 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 will consist on the one hand of improving the demonstration
implementation. 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
framework. For example, BPEL processes enhanced with business rules as proposed
by Rosenberg and Dustdar [
In this paper, we have discussed service continuity in mobile ubiquitous environments 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 continuity 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 transparently to service providers while remaining unaware of the actual service invocation 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.
Part of this work was supported by the Austrian Science Fund (FWF) project OMNIS.