smartphone enterprise application integration

Smartphone app usage is exploding, by both end consumers, and, more recently, by businesses using the most recent more powerful devices to make their workers more productive. One of the most interesting things about this trend is that it is a changed paradigm over most new applications done in the last fifteen years (which have been primarily centralized computing as web apps). By contrast smartphone apps are dominated by native apps running on the device itself, locally and utilizing device capabilities. This is truly “computing at the edge”, utilizing the incredible burgeoning power of the modern smartphone. Because of this many of the best practices that have emerged for enterprise applications need a serious refresh – new rules for optimal smartphone app development. One subarea of those overall best practices is how to most effectively integrate with existing enterprise applications. This is worthy of its own discussion.

In the enterprise scenario there are many common tasks that need to be performed to build an informational app that integrates with an existing enterprise backend app. This integration is proving to be the majority of the effort in building these apps, and in many cases the majority of an enterprise’s entire IT efforts. We will try to describe in more detail then where that effort is, and some best practices in reducing it and overall time to deployment.

When writing apps for modern smartphones to connect to enterprise backend applications, there are several areas of effort that must be solved to build the full app. You need to connect to the backend application, generally through some web service protocol. You need to retrieve the payload data from that backend. The data needs to be parsed into a consumable form. Generally the data needs to be stored locally on the device in some form of database. If the data is stored locally then some form of ongoing database management in the face of changes needs to take place. In some scenarios the data will need to be encrypted on the device. Finally there will generally need to be some way of making sure that the data and apps can be remotely wiped if the device is lost or stolen or the employee is terminated.

In the cases where synchronized offline data is required (most of the time for an enterprise app) many of these steps can be eliminated and the overall effort wil be simplified. But it also raises some additional steps to be performed: hosting the sync server, tying it in with the overall enterprise authentication directory, and writing some form of sync “source adapter” to interact with the backend application.

In talking with smartphone app developers we have found that all of these steps constitute more than half of every enterprise smartphone app’s code and overall effort. In the rest of this document we will break discuss each of these steps individually.

Connection
You will almost always want to connect via http or securely via https. You will need to think about how to handle authentication in a secure way. Generally you will want to use basic authentication challenges from smartphone devices versus some more elaborate protocol such as NTLM. On devices such as BlackBerry you may need to explicitly control which network (Wifi or carrier for example) is used as the transport.

You should try to execute some form of asynchronous connection to keep the smartphone user interface responsive. Many desktop apps and web apps can get away with synchronous connections where you wait for the response. On a mobile device you will want to keep the user interface responsive while you wait for the connection and information retrieval. So some method of connecting asynchronously with a callback on the return should be performed.

Data Retrieval
The first step in integrating to the enterprise backend application is to decide how to expose that backend. The common ways of doing this now are REST and SOAP web services. You may have inherited older methods such as DCOM, Corba or XML-RPC gateways.

Then the question is what is the payload format. Common approaches include XML or JSON payloads. JSON is much smaller and easier to process.

If you are communicating directly from a device we recommend a JSON payload exposed via a REST interface. When absolutely necessary you can connect directly to a SOAP service. But you would want to avoid this when using older BlackBerry devices. And you should be sure that the payload is not too large if you are doing this from SOAP.

When using a sync server, it may be OK to use some legacy method as the sync server can act as a proxying mechanism to make data easily retrievable by the device.

Parsing Responses
Once you retrieve the data you will then need to extract the data that your app needs from the payload. The options for doing this are most often either JSON parsing or XML parsing. If you are handling a large XML payload you will want to consider using either a stream or pull parser versus using the XML Document Object Model (DOM) to retrieve the data.

If you have a large amount of data (greater than 10MB) you will want to consider using some more efficient method than a text stream to get the data to the device. You could create some archived compressed format and deliver that in bulk to the client device (a technique sometimes referred to as “bulk sync”).

Populating the Database
Once you have the data, generally you will want to provide some way of populating a database or local cache. The user should not have to wait each time they start their app for their data to be retrieved from the server. You will want to populate some form of local database or cache. Generally this means taking the parsed data and creating records in database. Also in order to have users be comfortable creating or changing data for an enterprise application, you will need to give them a way to store their changes locally before it is applied. This requires managing the local database. It also generally requires some approach to data synchronization, which we will discuss shortly.

Secure Storage
In some cases if there is local data you will want encrypt that data before storage. This could be because of regulatory standards such as HIPAA. It could be sensitive information such as personal financial information or confidential trade secrets on a smartphone device with a chance of being stolen or lost. However, be careful when applying this technique. Encryption tends to be slow especially on older BlackBerry or Windows Mobile devices. Use it where necessary and nowhere else.

App and Data Deprovisioning
In the cases where sensitive data is on the device (whether or not the data is encrypted) you will want to have a way to deprovision apps and data if the device is lost, or an employee is terminated. There are many mobile app and device management solutions from vendors such as Sybase, Good Technology, Mobile Iron and Rhomobile. You should strongly consider having one of these solutions in place as part of your general app planning.

Data Synchronization
As mentioned, in enterprise application usage scenarios to get your app used you will need to provide some way for users to store their changes locally whether or not they are connected. One reason is the obvious one: so that users have their data and can do their work (such as creating and editing information) when they are offline. But the more critical reason is so that users know that their changes are made reliably, one and only one time. Users do email with rich client apps on their mobile devices – apps that store data locally and sync the email in background (versus using a mobile web browser). They have the same expectations for their enterprise apps. Finally having the data available locally creates a faster user experience – the data is always available for them immediately on startup.

A side benefit of using data synchronization is that it simplifies the app integration scenario just described above. Instead of doing all the work to connect, retrieve, parse and store the data, a good synchronization server and client app framework will perform all of that work. The only task for the app developer is to write the code for the sync server to connect to the backend application. That work is typically called a “source adapter”. The app developer needs to write code to enable the server to retrieve or query information. If they want bidirectional data they will need to write code to create, update and delete information as well. This is typically much less code than performing all of the connection, retrieval, extraction and storage from the device. And usually the sync server has a richer set of libraries and tools available to make those backend connections. The server can usually handle whatever format the backend application exposes, versus requiring a new web service to be exposed.

There are several things that you should look for in a sync server and sync client framework if you want to have an optimal solution. First of all your server should support “push sync”. This means that changes made to the backend application get immediately sent to the devices that need them. This avoids the device having to “poll” occasionally for changes. Polling results in mobile device battery drain and some level of staleness of data for the user. Note that your backend application must have some kind of notification mechanism exposed. Also there must be some way of performing a push to the device to make this work. It is unusual “homegrown” approaches to sync to do push.

Conclusion
If you are considering building an enterprise app for modern smartphones, we would encourage you to look at each of these steps to performing integration with your backend enterprise application. In the next post we will describe how RhoSync makes each of these steps easier. But thinking carefully through each of these issues is likely to accelerate your development efforts and result in a better solution, whether or not you use Rhomobile products.