Anyone who builds mobile applications or supports mobile devices as part of a worker-empowerment or consumer-experience delivery strategy has likely heard about mobile middleware. Properly selected and used, mobile middleware can radically reduce development time, enhance the user experience, and facilitate security and compliance governance. While the general mobile middleware model is standardized, there are variables in data management and mapping and in overall application design that need to be addressed when middleware is being optimized to applications and policies.
Optimizing mobile middleware design
The ideal mobile middleware architecture has a server element from which logical applications are delivered. These applications are consumers of data or application program interfaces (APIs) that represent external services or data access, which is the back end of the middleware layer. In front of the server are the APIs or interfaces where information and experiences are delivered. This creates the traditional four-level structure of user-to-server-to-application-to-resources.
Two of the early design questions this simple structure brings out are "What's an application?" and "What's a resource?" It's possible to expose a Web API, for example, as an application; doing that would mean it can be accessed directly by users. The problem with allowing users direct access to a Web API is that such access bypasses whatever logging, security and governance that might be provided by the middleware -- it's really a user-to-resource link. In some cases, such as where you're delivering a video and performance is critical, this sort of direct-connect exposure of resources is a risk you're better off avoiding.
The corollary to that point is that good design practices should begin with the applications' creation. Start with the framework through which you intend to supply security and compliance support, logging of activity, and so forth. To the greatest extent possible, all your applications should fit into this framework structure to ensure that practices are applied consistently.
A critical question with your mobile middleware application framework is the exposure of APIs. If you expect to support browser access (which likely you should), the basic application must present a RESTful front end. It's also expected that most mobile device applications use RESTful APIs. If you also intend to use RESTful APIs, design all your applications for Representational State Transfer (REST). Doing so means you can't presume the application will maintain state. That will be important when you look at your application-to-resource links.
Paths to improving performance
Where applications will access your middleware directly using Web services, you'll need to review the APIs supported by each platform that your BYOD policy -- your practices on supplying mobile devices to workers -- includes. Make a chart to show all the APIs supported by each platform and align them to find the smallest number of APIs that fit your requirements.
Mobile middleware can radically reduce development time.
In many cases, it's necessary to provide a different front end for each API supported. Rather than duplicate the application logic for each user interface, consider building multiple front ends that dispatch the work to the same application behind. If you do this, you can establish a common data model for all APIs and adapt that model to the specific APIs (and to HTML). This will simplify your application lifecycle management processes if you experience regular changes in the APIs because of changes in device operating system or your own mobile device policies.
Some steps to decouple APIs from application logic may also be helpful on the resource side of your middleware. The common data model you defined for the APIs on the access side is the baseline for what your data model needs to include from the resource side. Add in any elements that are used internally by the application rather than presented to users, and you have a working resource-side model. You should then use a back end (actually a front-end interface facing backwards) to interface with any resources.
One of the challenges with this approach is performance, which may be an obstacle for mobile middleware in many cases. To gain maximum flexibility, you may want to couple multiple APIs loosely at both the resource and user sides of an application, which requires more handling of messages and reduces performance. Where optimum performance is needed, you may have to forego some flexibility and hard-code the interfaces to users and resources, even duplicating application logic.
There could be another path to improved performance -- the scale-out process of instantiating multiple copies of middleware. This will improve performance as long as the application, middleware and user-API side of the connection are the problem. If you're limited by database performance, for example, replicating middleware copies won't help.
When moving large quantities of data through mobile middleware, beware of performance problems that virtualization or the cloud can create. Network traffic might not be passed efficiently to virtual machines (VMs) depending on the hypervisor used and whether data-path optimization is in place. This can be particularly problematic if mobile applications move traffic between multiple VMs on the same host; bridging of the network connections can be very inefficient. Check with the hypervisor or cloud software provider for the techniques available to optimize the data path, particularly for the delivery of mobile video.
Mobile middleware can be very sensitive to loss-of-connection problems, particularly if the mobile activity involves some commitment of resources or a financial transaction. The path from user to resource for all these types of activities should be thoroughly examined and tested to insure that faults don't leave a user committed to something they don't realize they have, or leave resources stranded without owners.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.