Figure 1. First Generation Mobile Applications

First generation mobile applications were fraught with disappointments. Sluggish, browser-based applications on devices with tiny black and white displays were frustrating to use over high latency, dial-up wireless networks. When network or server access was unavailable or intermittent, the applications failed to work. Figure 1 depicts the early mobile application architecture. All critical application data, business logic and user interface logic were placed on the server. Consequently, the responsiveness and availability of each user request was entirely dependent on network and server availability.

MIC addresses these problems by enabling a new class of highly interactive applications on internet-connected, programmable devices that have local data storage and often larger color displays and better input devices. MIC applications respond immediately to user requests and continue to work when network access is intermittent or unavailable.

Figure 2 depicts the MIC application architecture. Critical application data, business logic and user interface logic reside on the mobile device. Synchronized data and additional business logic may reside on the application server.

Figure 2. MIC Applications

MIC applications and application servers operate independently, sharing information and business logic in the background via standard, device independent web services protocols (i.e., XML, SOAP, WSDL). This allows MIC to integrate directly with existing web services applications regardless of the enterprise environment (e.g. Java J2EE or Microsoft .NET). Information updated on backend servers is available to mobile users and information gathered by mobile users is available to the backend server

The maximum size of an application on most mass market mobile devices is limited to 64 kilobytes or smaller. However, the typical technology stack required to implement XML and web services requires over 20 times that amount of memory. Attempts to build smaller, watered down mobile web service implementations have been problematic. They typically remove features required by a large percentage of web services, making a large amount of internet information inaccessible. They also push complex programming problems up to the developer, making mobile application development more difficult, time consuming and error prone. Although smaller, these implementations still require a disproportionate amount of the mobile device's resources leaving little to no room for application features. The chart below illustrates the amount of memory required for a typical application using a popular mobile web services toolkit called kSOAP and compares it side by side with the amount of memory required by MIC. Where kSOAP leaves just enough room for a very simple demo application, MIC leaves room for a fully featured application. In addition, MIC includes an intuitive binding layer that simplifies and accelerates application development. Unlike other approaches, MIC does not delegate complex programming problems to the software developer or eliminate features required by a large percentage of web services.