Mobile Application Architecture Copyright 2007 Rus Shuler, Enterprise Architect Why Go Mobile?

? With the proliferation of affordable, handheld computing devices, there are few reasons not to. Your competitors probably are and you should too. Here are a few reasons whyy y y y

Eliminate Paper-Oriented Processes Keep Employees On The Road Information Anywhere Extend Business Processes To A Mobile Workforce

This whitepaper addresses challenges of mobile system development and some of the architectures used to implement real mobile systems.

Mobile Architecture Overview Most mobile systems extend an existing business system or interface with an existing system. There are typically three major components to a mobile architecturey y y

An existing system A middleware application A handheld application

The reason a middleware application is usually needed is to provide data transformation, apply business logic, and be a central point of communication for the devices. If a new business system is being developed or rewritten then no middleware may be necessary; the appropriate logic can be built into the system to communicate with the devices from the start. However most business systems are not rewritten very often and it is economically unfeasible to rewrite them just to 'mobilize' them. Furthermore a middleware server may also serve a configuration management server. The architectures shown here are real-world architectures from actual projects. These mobile systems are in production in numerous locations.

Mobile Challenges

Without addressing specific challenges a mobile engagement will not be successful. Challenges faced on most projects will includey y y y y y y

Interfacing Disparate Technologies Device Configuration Software Deployment And Upgrades User Interface Design Performance Memory Management Security

Interfacing Disparate Technologies Mobile system development often involves using different technologies due to platform restrictions. In the three architectures below, two use both Microsoft and Java technologies. In both cases applications developed in these disparate technologies must communicate seamlessly with each other. Web services, HTTP, and TCP sockets were used to bridge these gaps. A mobile system development team must have the skill and experience to determine the best data transfer design. Device Configuration If the application is being deployed on new handheld devices, there is a good chance that some configuration will be required. After a device is cold booted, the deployed application must be reloaded and the 802.11 wireless configuration must be restored. Different manufacturers use proprietary methods for loading applications and configuration settings. If the users should not have access to the OS (e.g. to play solitaire) then a top-level menu application may be needed to run at system startup. Device scanners must be configured with the correct barcode symbologies and symbology options. Configuration options may need to be remotely managed as well. Software Deployment And Upgrades Beyond device configuration is software deployment. The application or suite of applications must initially be loaded or provisioned on the device. If there are many devices, this may be a formidable challenge. There are software packages that manage device software and configurations. These packages rely on a software client on the device. Proprietary packages must typically be written for the management applications that specify the software and configuration files to load. If no management package is used, the application should be selfupdating. Having the users send in their devices to have software reloaded is usually unrealistic. User Interface Design Designing the graphical user interface (GUI) on a mobile device can be challenging because of the small screen and difficult data entry. If the application or data is complex, the user will need to interact with many screen objects such as entry fields, lists, and radio buttons. Complex screens will need to be divided into separate screens or tabbed interfaces. A wizardlike interface may be appropriate for some applications. Some applications on pen-based devices may require that a stylus is not required and the device's physical keys must be used

instead. If a lot of free-form data entry is required then a tablet or notebook PC should be considered. Performance Servers and desktop computers have progressed significantly and performance is typically not an issue anymore. Handheld computing devices are another story however. Many are very slow by comparison. Complex user interfaces, CPU intensive algorithms, and data processing can easily make an application user-hostile. Care must be taken during design to avoid performance pitfalls. One pitfall in Compact Framework development is using ADO.Net DataSets. They are very slow on most handheld devices. Memory Management Although memory is cheaper than ever, most mobile devices come with a set amount of memory and cannot be upgraded. If systems analysis shows that data requirements include having large amounts of data on the handheld, this may limit your hardware choices. Efficient data storage is necessary, and low-level interfaces may be required to make the most of the memory available. Because cold boots typically erase all non-volatile memory in the device, design must ensure that critical data is stored in non-volatile memory. Security Security is a concern in many systems and mobile systems are no different. Mobile systems introduce a few new issues however. What if the mobile device is lost? A stranger cannot be allowed access to your sensitive business data. Some hardware includes thumbprint scanners to authenticate users. A user login may also be implemented so that users must present a set of credentials before application use.

Data Transfer Data transfer is a significant part of mobile application architecture because of the number of 'hops' the data must make. The methods and protocols should be carefully considered during system design. The typical tradeoffs arey y y y

Security Ease of Implementation Reliability Cost of Ownership

If the application is run on a secured LAN, then security considerations may be low. If cost and ease of implementation are factors, then a less reliable method may be used. If reliability must be guaranteed, then a more expensive communication mechanism should be considered. Several choices for network communication are listed here-

y y y y y

Web Services Queueing Services TCP Sockets HTTP FTP

Web Services Web services are relatively easy to implement and existing web services in a service oriented architecture (SOA) or an enterprise service bus (ESB) may potentially be used. Web services are technology agnostic and may be used between most platforms and technologies. They are not well suited for large, binary data files. Security is available, but may be more difficult to implement between heterogeneous technologies. Queueing Services Queueing services guarantee data delivery. They may also be configured for store-andforward capability. There are few queueing packages available for mobile devices and may be cost prohibitive. Queueing technologies for servers are well established and several good choices exist. TCP Sockets Transferring data over a raw network socket offers the greatest speed of all methods. If security is required it will need to be implemented in code, usually with an encryption library. Implementation can be quick if only raw file transfer is required. Multithreading will be required on the server so that multiple devices can connect simultaneously. If something more complicated than file transfer is required then another method (such as web services) should be considered so that a complex custom protocol does not have to be developed. HTTP HTTP can provide an easy way for an application to send messages and receive data from another application running a web application. SSL can easily be used to provide security. Implementation is not complicated. FTP Although usually not preferred, FTP still has a place in system integration. This may be the only way to transfer data to older business systems. If FTP is chosen as a data transfer method, consideration must be given to an appropriate threading architecture with retry capability. Most FTP servers are not configured with encryption, but may be set up to provide it.

Disconnected Architecture This system is deployed in more than twelve manufacturing plants and eliminates clipboards and manual data entry. The biggest installation has over sixty users. At the time of this

writing, this system has been in production for more than four years. It will continue to be improved and modified over the coming years. This architecture addresses these high-level requirementsy y y y y

Business data (e.g. customers, materials, etc.) is available on the device. Business data may be large (+6MB/file). The device may be used in a disconnected mode, e.g. out of the office. Users enter data, return to the office, and send the data to the business system. The only interface available to the business system is FTP.

This system was developed with Microsoft's .Net Compact Framework while it was in Beta stage and the .Net 1.0 framework. The code base was later migrated to the release Compact Framework and .Net 1.1.

Business System The business system is a SCO Unix platform running a manufacturing shop floor management system. The only interface is via FTP and the import/export interface already exists on the SCO server. Data from the handheld devices must be manually imported in the business system by a menu choice, but this was later eliminated. Middleware Application

The middleware application is comprised of a Windows service, a web service, and a multithreaded TCP socket server. It is responsible fory y y y y y y y y y

Downloading business data from the SCO server. Transforming this data into smaller files that are better organized for the handheld application. Serving these data files to the handheld applications via the TCP socket server. Receiving data from the handhelds via the web service. Applying business rules to the inbound handheld data. Creating reports using Microsoft Excel. Sending the data to the SCO server. Providing administrative control with a web application. Optionally, sending the server and handheld logs files to a central logging server. Optionally, getting software updates from a central software server.

A Windows service was chosen as the core application and runs all the time. This service is multithreaded and uses a queue to process tasks in order. The TCP socket server was chosen to transfer the large data files to the handheld as quickly as possible. The web service is used to implement control functions and small data transfers. The FTP interface runs on its own thread and all data transfers will retry if there are network problems. Handheld Application The handheld application is comprised of more than fifteen screens. Users must log into the application with a username and password. The data validation logic is part of the business data from the SCO system. The hardware used to run the application are ruggedized Pocket PCs that contain non-volatile memory and optional Bluetooth and wireless networking. If Bluetooth is available, the application can print reports to a mobile Bluetooth printer. The application is self-updating; it downloads new software via the socket server from the middleware application.

Cellular Phone Architecture This system was developed for a large logistics company. Truck drivers carry cellular phones running the mobile application. The application informs the drivers of new jobs, allows entry of pickups and deliveries, and general messaging. This architecture addresses these high-level requirementsy y y y

The system must guarantee message delivery. The system must store messages if a mobile device is out of the cellular data network. The mobile application must still allow data entry when out of network. The system must accommodate over 3,000 users.

The middleware was developed using Microsoft's .Net technology using a web service, a Windows service, and remoting. The mobile application was developed in Java using J2ME (Java 2 Mobile Edition). IBM's MQ-Series technology is used for queueing between the middleware and business system.

Business System The business system runs a large logistics application on IBM hardware. The application is a customized package application using DB2 as a database. All messaging to this system must occur via MQ-Series. Middleware Application The middleware application uses a Windows service to configure the remoting infrastructure. The web service used by the mobile application accesses the application's business classes via remoting. The middleware is responsible fory y y y y y

Receiving and sending messages from the business system. Aggregating messages for a mobile device into a single message using a message envelope. Receiving messages from the mobile application. Processing messages from the mobile application in order. Creating a message envelope containing all messages for delivery to a mobile device. Storing messages from the business system for a device until that device connects.

Due to restrictions in the cellular provider's network, the middleware cannot "push" messages to a device. A web service was chosen to receive messages from the devices for this reason, and also because the mobile application is written in Java. Remoting was used to allow the web service to pass the message packet from the mobile application to the business layer. The business layer processes the message and always returns a message packet to the device via remoting and web service. Handheld Application The handheld application runs on a Motorola iDEN cellular phone running a proprietary operating system. The application was developed in Java since this was the only choice available. Java 2 Mobile Edition (J2ME) technology was used to develop the mobile application. The mobile application is responsible for-

y y y y y

Always running even when the user interface is not in use. Sending messages to the middleware including occasional "ping" messages. Storing application data on the device as needed. Audibly alerting the user when certain messages are received. Resending any messages when exceptions occur.

The mobile application is multithreaded. One thread always runs to send and receive messages and another thread runs the user interface when invoked. Data storage uses the J2ME record management facilities.

Wireless LAN Mobile Web Architecture This system is used to activate individual item price changes in a large retail chain of over 1,100 stores. Each store has wireless 802.11 networking installed and connectivity to the chain's headquarters. Users scan an item to activate the new price then hang a new shelf tag. This system eliminates thousands of staff hours and has an ROI of over $5M/year. This architecture addresses these high-level requirementsy y y y y y y y

High reliability. Easy installation and administration. The system must interface with the point-of-sale (POS) system in each store. Complex pricing rules must be implemented. The handheld application must be a web application; there should be no code on the handheld device. The system must be asynchronous, i.e. users can scan a barcode to activate a price and not have to wait to scan another item. The system must operate in near real-time, i.e. price changes must be seen at the registers immediately. There must be a desktop reporting application.

This system was developed using Microsoft's .Net framework 1.1 and Java 1.1.8.

Point Of Sale System The POS system in each store runs IBM's 4690 OS. Java was chosen as the development platform over IBM's CBASIC and C due to resource availability and cross-platform functionality. Java 1.1.8 had to be used due to the system configuration. Because the system had to be asynchronous, the POS application and the middleware application had to be able to send messages to each other at any time. The POS application is responsible fory y y y y y y

Detecting price change batches from the headquarters mainframe. Signaling the middleware application that a price change process is running and when it is complete. Providing the price change data to the middleware application via the socket server. Receiving price change commands from the middleware application to modify the price of a single item. Submitting price changes to the delayed data maintenance (DDM) facility to modify the POS item file. Signal the middleware application when the price change is complete. Recovering from reboots and network failures that may occur at any time.

The application could not write to the POS item file directly; it had to interface with IBM's delayed data maintenance (DDM) facility. The socket server was chosen to receive messages from the Windows middleware application (there simply weren't that many choices). The communication interface to the middleware web application uses HTTP POSTs to send predefined messages and data. The application is multithreaded and very robust.

Middleware Application The middleware application was developed in .Net, runs on Windows 2000 and 2003, and uses Microsoft's SQL Server Desktop Engine (MSDE). It is responsible fory y y y y y

Running the mobile web application and receiving price change requests from users. Not allowing use of the system when a price change process is running on the POS system. Retrieving and storing price change data and cross-reference data from the POS application. Maintaining price change data in it's database. Receiving messages from the POS application regarding item price status, batch status, etc. Enforcing price activation business rules contained in a configuration file.

A small web application was chosen to receive messages from the POS application because it is inherently multithreaded and easy to implement. A custom communication protocol and interface was developed to send messages to the POS application's socket server. A web service is the interface for the mobile web application, the desktop reporting application, and the POS web application. This allows a single point-of-entry into the core application business logic. Handheld Application There is no handheld application since the mobile web application is run in Internet Information Server (IIS) on the Windows 2000/2003 server. The devices used are ruggedized Pocket PCs with a special web browser provided by the device's manufacturer. This specialized web browser runs in fullscreen mode. It has no frame, address bar, etc. and so appears as an application running on the device. The browser allows control of certain device hardware through the use of JavaScript and HTML meta tags. This allows control of the barcode scanner and the physical alphanumeric keys on the front of the device. No stylus is used on the device, only key commands.

Take Away Mobile systems can enhance business processes significantly by extending existing business systems. Here are the key take-aways of this whitepapery y y y y y

Typically a middleware application must be developed in conjunction with a mobile application. In many cases the technology used to develop the applications will be different. Identify and understand the technological challenges early in the project lifecycle. There must be a plan for configuring, provisioning, and upgrading software on the devices. Data transfer is a key component and must be carefully considered. Mobile system architectures vary by device application types, networking scope, and data transfer methods.

Now get out there and get mobilized!

M-banking :
By M-banking we refer to financial services delivered via mobile networks and performed on a mobile phone. These services may or may not be defined as banking services by the regulator, depending on the legislation of the country in question, as well as on which services are offered. Hence, we may refer to an initiative as M-banking service even though it would not fall into the banking definitions under that particular countrys regulatory regime. As described previously, M-banking is by Porteous (2006)4 separated into two categories; additive and transformational, where the latter is categorized by a new type of services that could attract users from rural areas and poorer segments of the market, and hence can have a transformational effect. When we casually use the term M-banking, we refer to transformational M-banking services

M-transactions :
Transactions such as remittances and payments delivered via mobile networks and performed on a mobile phone..