Dr Mícheál Ó Foghlú (CTO, FeedHenry) and Anthony Rizk (Lead Mobile Developer, VMware)
Mobile apps are the way that users interact with services on their smartphones. The main challenges with enterprise mobile apps are:
- the fragmented nature of the smartphone market – there are several significant and mutually incompatible platforms: iOS, Android, RIM, WP7, …
- access to enterprise back-end systems from mobile devices securely in a way that is appropriate for mobile data.
- Cloud Foundry and FeedHenry provide a secure, easy to set up solution for developing and managing enterprise mobile apps; VMware has successfully developed and released a widely used mobile app – My VMware for iOS and Android – on this technology stack Outline
Table of Contents
- Introduction – the Mobile App market, challenges and opportunities for enterprises.
- Solving Mobile Platform fragmentation with HTML5 hybrid apps.
- Mobilizing enterprise data systems with a MEAP.
- Cloud Foundry and FeedHenry – cloud-based, cross-platform mobile apps.
- Case Study: My VMware mobile app
Introduction – the Mobile App market, challenges and opportunities for enterprises
It was the introduction of the iPhone in 2007 that really created the new market for mobile services packaged as apps. The iPhone did build upon the huge developments in mobile data, mobile services and mobile web that earlier smartphones had established, particularly using the J2ME software development paradigm, but the iPhone made the user experience closer to the desktop one, and pioneered intuitive touch interfaces for mobile devices. The pace of innovation quickened even further with the launch of the iPad in 2010. Since the iPhone launch Google’s Android platform, that can be used on both smartphones and pads, has gained significant traction, offering the only alternative with significant market traction to date. RIM’s BlackBerry and Microsoft’s Windows Phone do have some penetration, the former especially in enterprises.
The iPhone and iPad are primarily consumer devices, but riding a general trend of consumerization of the enterprise, these devices are increasing being deployed within enterprises either under a BYOD (Bring Your Own Device), or under a traditional managed device for employees by a central IT department.
Perhaps the best statistical summary of how Internet services are impacting on consumers and on enterprises is arguably the annual slide deck “Internet Trends” presented by Mary Meeker (formerly Morgan Stanley now KPCB) at the Web 2.0 Summit each year [1a], and other event [1b]. Over the past few years the rise of the mobile devices, of the app ecosystem that supports them, and of the growing numbers of users of services delivered via this ecosystem, has been the main theme. Her slides show that the iPad and iPhone have been the most successful consumer devices ever launched, and the Android has had a very significant market impact.
Solving Mobile Platform fragmentation with HTML5 Hybrid apps
There is no single dominant smartphone platform – both Android and iOS have significant marketshare. With the rising trend of BYOD, both are widely used inside enterprises. BlackBerry is still a significant presence in some areas, and Windows Phone may yet achieve greater market penetration. The opening up of the tablet market has made this problem worse. Certainly iPad is dominant, but Android tablets are gaining share and other entries such as Windows 8 are on the horizon. These platforms generally have entirely incompatible developer tool stacks (i.e. Java with Android’s SDK on Eclipse or another editor vs. Objective-C and XCode for iOS). Enterprise developers therefore must support at least two mutually incompatible platforms, and in some cases three or more. This obviously significantly increases development and maintenance costs.
It makes sense to evaluate the cross-platform options available. One option is to avoid the app ecosystem entirely, and to develop a mobile web page that provides a service. The main disadvantages of this approach are that web pages have very limited permissions on the device, and so cannot integrate easily with the device features that make them so compelling (e.g. camera, accelerometer, GPS positioning, contacts DB). In addition most users currently look for solutions within the app ecosystem, rather than on the web, and so potentially users will not find these solutions.
There are two main categories of enterprise use case for mobile solutions: 1. Create mobile access to an existing solution 2. Create a new (mobile-only or mobile-first) solution
In most cases both of these scenarios will require integration with some existing back-end enterprise systems (e.g. authentication at the very least, even for ‘mobile-only’ solutions).
Given that hybrid apps do not use a web server by default – they are self contained on the device – this means that if the requirement is for mobile devices to access these internal enterprise systems there are two options:
- Open up the enterprise end points to the world, and harden them (e.g, via authentication) to prevent abuse; this would then allow mobile apps to directly call these end-points
- Introduce a middleware layer (in mobile solutions – a MEAP) to protect the end points acting as a gateway; this allows the end points to remain closed to world access, with various options for communication with the gateway such as locating it locally or putting it external with some from of VPN back to the end points being protected; the mobile apps just call the gateway which then calls the end points
The second option is preferable for a number of reasons:
End-point security is only the initial justification for the use of some form of middleware layer in any mobile enterprise solution. The case in general for N-Tier architectures has been made in Enterprise IT over the past 30 years. Specifically for a mobile app solution it makes sense to minimize the client-side updates as much as possible as it a relatively heavy process to require end-users to update the app on device (though in some scenarios a Mobile Device Management solution could enforce these updates). Instead, changes made on the server-side can be dynamically deployed with immediate effect for all users. Thus it makes sense to treat the client-side app as a highly flexible view component, and allow the middleware to deal with changes to the end points as much as possible.
Using a cloud solution to host the middleware makes a good choice for mobile apps. It’s difficult to predict what downloads will be and almost impossible to predict usage for most apps, so having a solution that scales quickly to meet higher than expected demand is very desirable.
Cloud Foundry and FeedHenry – cloud-based, cross-platform mobile apps
Cloud Foundry provides a Node.js runtime environment, and Node.js apps are well supported by the Cloud Foundry deploy tools. FeedHenry is a cloud mobile application platform which targets Cloud Foundry for server-side deployment.
It is free to register for a public Cloud Foundry account and FeedHenry account at https://mobilecf.feedhenry.com, and this gives the ability to create new apps, or clone some existing template apps, build a cross platform client-side for supported platforms (iOS, Android, BlackBerry OS 6.0+, Windows Phone 7.0+ and Embedded Web).
For a full tutorial on building your first mobile app, server-side and client-side, on this platform see this post on the Cloud Foundry blog.
Case Study: MyVMware mobile app
In April 2012, VMware launched the My VMware mobile app which is publicly available via the Apple App Store and via Google Play for Android.
Figure 1: Screenshot My VMware iPad app
The mobile app was one element of the larger My VMware project that required the development of new web service API wrapper for the back-end enterprise systems.
The core functionality of the app is to provide read-only access to the licence entitlements of each customer. Thus a user can browser all of the licences and see who they have been assigned to within the organization. Once license info has been synced to the device, the app can work in situations without radio coverage so that e.g. an administrator can take their tablet or smartphone into a data centre to verify licenses.
The platform enabled rapid application development with working versions of the cloud (Node.js) and client-side (Sench Touch) code produced each iteration. Initial iterations were longer, with iterations towards the end of the project being 2-3 weeks in duration.
The revision control software used to manage the codebase was git, in this case hosted inside a hosted project management tool suite Unfuddle. FeedHenry is integrated with git so that commits to the git repository are easily updated into the FeedHenry app, and a post-commit trigger can be enabled to auto-sync FeedHenry with the latest committed version of the software in the repository.
The data to drive these queries is provided via an Oracle Service Bus (OSB) using XML SOAP requests. The XML responses are consumed on the Node.js cloud component of the app, and any data required by the client-side is transformed into JSON (using a third party SOAP parsing module). In some cases, multiple SOAP requests are consolidated into one JSON payload for the client – this addresses the inherently higher latency of wireless network connectivity.
The cloud piece also handles caching and some session management on behalf of the client – caching is done with Redis, exposed through Node.js via FeedHenry’s platform. The Node.js middleware is connected securely to the OSB endpoints, and the client communicates with the Node.js middleware over HTTPS.
The app does also make use of the Sencha Touch model/store architecture but this is mostly done for purposes of easily populating data into the UI.
The app is optimized for tablet devices, particularly the iPad and Android tablets. An alternative workflow taking into account the more limited screen real estate of smartphones is also provided. This means it can be used on Android tablets and smartphones, and on Apple iPad, iPhone, and iPod Touch devices.
With several thousand downloads and a lot of daily use, there have been no service problems with the apps on either the iOS or Android platforms, and VMware is investing in further development of apps using the same platform.