Mobile devices use wireless networks that have limited range. Therefore, they may not always be connected to a network. This kind of intermittent connectivity in mobile devices has been one of the factors inhibiting enterprise-level adoption of pervasive mobile applications. Occasionally Connected Computing (OCC) deals with this problem. The challenge that mobile application developers face today is to develop applications that will let users interact uniformly with the application regardless of the connection status.

In the recent past, Web Services have appeared as a key technology for mobility with support from leading mobile platforms. However, leveraging Web Services for occasionally connected mobility applications falls flat because of a lack of reliability. In this article we present a framework that enables OCC using Web Services Reliable Messaging (WSRM), which can be a catalyst for enabling occasionally connected mainstream mobility applications. For our framework, WSRM provides the reliability required for Web Service communication in occasionally connected environments.

This article is divided into three parts. The first part surveys the relevant background material on Web Services support in mobile platforms, WSRM, and occasionally connected computing. The second part explains a typical use case for occasionally connected mobile computing and explains our framework and implementation details. The last section provides conclusions on this work and identifies further scope for future work.

Overview of Mobile Platforms and Web Service Frameworks
Mobile devices today not only include the common mobile phones, but also smartphones, PDAs, small form factor tablet PCs, and so on. These devices vary significantly on hardware and software configurations. Here is a brief overview of the most common mobile platforms. Most modern rich mobile devices use one of the following operating systems:

1. Symbian OS is currently the most popular Smartphone operating system. It is an independent Open Source project. The OS isn't found as such on devices but customized according to a manufacturer's needs. Nokia phones use a series of Symbian-based interfaces known as the S series (such as S60, S90) while Sony Ericsson devices have UIQ platform interfaces. Symbian runs mainly J2ME applications and has a dedicated Java execution layer. It's not found in PDAs without phone functionality.
2. Windows CE runs on a variety of mobile devices such as PDAs, Smartphones, and hybrids. The various versions of CE are given different names such as Windows Mobile 2002 and 2003 along with different editions of the same such as PocketPC, Smartphone, and PocketPC Phone. The latest version is Windows Mobile 5.0. It uses the .NET CF platform for development.
3. PalmOS can also be found in many mobile PDAs and phones, such as the popular Treo line of devices. Being the first dedicated mobile OS, it has a huge library of applications. Coding is done primarily in C/C++.
4. Other OSes such as Linux and its embedded versions can be found in specialized devices. BlackBerries use a proprietary OS. However, they represent a small niche of the market.

At the language level, most of these devices natively support either the Java or .NET platform.

1. Java is implemented on mobile devices using the Java 2 Micro Edition (J2ME) platform. Programs written for J2ME are similar to normal Java programs, except they have smaller libraries and are written for a more compact virtual machine. Due to the large Java developer base and robust and open community, J2ME is by far the most popular mobile language platform.
2. Microsoft's .NET Compact Framework (.NET CF) for mobile devices lets developers program for devices that run Windows CE versions such as PocketPCs and Windows Mobile Smartphones. Integrated into the popular Visual Studio toolset, it has an intuitive and easy-to-use GUI to build and test mobile applications as well as excellent native XML support.
3. Other languages such as C/C++ are also supported on some OSes such as Symbian, Palm, and BlackBerry.

The diversity in application platforms as detailed above poses serious interoperability problems and is a cause of the high cost involved in developing enterprise mobility applications.

A recent trend in these mobile platforms is the inclusion of support for open standards like Web Services. This can be a crucial enabler of interoperability across diverse mobile platforms and of enterprise mobility applications that can be treated as extensions of conventional enterprise applications exposed via services to mobile devices. We explore the support for Web Services in different platforms below:

1. .NET CF offers native support for calling and handling Web Services, as well as complete XML processing capabilities, such as support for XML schemas, Xpath, and XML serialization. Due to the integrated nature of the framework and full support for SOAP and other protocols, the Web Service support in the CF is well-rounded and simulates functionality available on larger devices
2. The J2ME platform also supports Web Services, but not at the advanced level found in .NET CF. Basic Web Service clients can be made using the Java SOAP toolkit but until now such functionality wasn't natively available in J2ME itself. Sun has come out with JSR-172 to address these issues. JSR-172 aims to provide access to remote SOAP- and XML-based Web Services and to provide XML parsing capability in J2ME. With wider adoption of these new features among developers and frameworks like kSOAP and MIC already available, native Web Service handling in J2ME should come up to the level of the .NET CF implementation.

Web Services Reliable Messaging
WSRM is a specification by Microsoft, IBM, Tibco Software and BEA Systems for the reliable delivery of SOAP messages. By using this specification the sender can make sure that the Web service message actually reaches the Web service receiver and is not lost in transit. To implement this, the sender may store the message before sending it across to the receiver and delete it only when it gets an acknowledgment from the receiver. If the receiver fails to acknowledge the message, it's assumed to be lost and is re-sent. This is the most basic form of WSRM and is called a 'once and only once' delivery assurance profile. There is also a 'at most once' profile where one tries to reach the Web Service just once. If it fails, the message is lost. Although this defeats the purpose of having WSRM, it can be quite useful as we show in our use case.

In Figure 1 the initial sender sends a message for reliable delivery. The source accepts the message and transmits it one or more times. After getting the message the destination acknowledges it. Finally, the destination delivers the message to the ultimate receiver.

Current Work in Occasionally Connected Computing
Before proceeding further, it's imperative that we understand the current work and research done in this area. While not many initiatives or products have taken off, the existing attempts can give us valuable pointers as to the advantages and drawbacks of such a scheme.

To handle occasionally connected scenarios, the MiddleWare Company extended the SOA Blueprints Reference to come up with the Occasionally Connected Profile (OCCP) v0.1 in 2004. This reference architecture was later handed over to Oasis for ratification and standardization through a community process. The profile covers an architectural framework that states that the user should be allowed to work offline and cache data locally when a connection isn't available and when the connection is restored, the cached data should be sent to the server. However, this profile has some limitations like its requirement for a mobile database for persistence, its scope of coverage in terms of the range of mobile devices covered, etc. Notwithstanding certain limitations in the draft OCCP specification, it's a farsighted attempt to specify a framework for mobile applications considering that when it was drafted, Web Services and XML weren't as prevalent as they are now. Most mobile platforms didn't support them natively either so the OCCP draft's shortcomings have to be evaluated in this context. It's a genuine forbearer of architectures such as the one we're suggesting.

Use Case
To drive home the requirements of a realistic architectural framework leveraging OCC, we propose a comprehensive use case. We assume an "Inventory Management System" in the context of a mobile sales force application to depict the ever-increasing need for connectivity in an enterprise for its mobile work force. This system provides services like submitting a customer order, querying the current inventory status, and initiating the order process with a supplier to replenish inventory.

These services have to cater to the needs of three kinds of users, all of whom can place a customer's order and view the required inventory status: a field salesperson who is on the move and has to access these services through a Symbian smartphone, a manager moving around with a PocketPC device, and an in-house salesperson/manager/employee who has a laptop or PC and can place a customer's order or order from the inventory supplier through the company portal. To make the services available to the different users, they are available as Web Services. Access to the portal requires that the devices always be online. But with mobile devices having intermittent connectivity, this isn't always possible. So these devices have a client application installed through which they can access these Web Services. This setup is shown in Figure 2.

Access to these Web Services is role-based. The salesperson can see the current inventory status and submit customer orders whereas the manager has the extra privilege of initiating the order process with the supplier for refilling the stock.

We have assumed that the enterprise uses an optimistic approach for its sale process. Here the salesperson will have a fixed quota out of the total stock in inventory. This will enable the salesperson to create and submit customer orders when he's not connected. In this case he will create orders only within the allotted quota. The client application lets the user submit orders as if he were online and when he's connected again, the submitted orders will be sent to the central repository and the order processing may start immediately. However, if he's connected he can view the real-time inventory status and take orders beyond his quota. The decrease in inventory may result in triggering a re-order alert to replenish the inventory. The trigger will make the manager aware of the current inventory status so that he can initiate the re-order with the supplier. Hence a perfect balance can be maintained between the current stock and the customer orders. The manager can also initiate the re-order at his discretion and market speculation. The application will make sure that the order to the supplier is initiated even if his mobile device isn't connected by using WSRM to send the request upon receiving connectivity transparently.

Framework
Occasionally connected computing requires the presence of a client application that lets the user work and store his data offline. Figure 3 shows the high-level components needed to develop such an application.