Chapter 5. Mobile Enterprise—Beyond the Mobile End-Point

Enterprise backend “Systems of Record” are a rich source of services and data that can greatly differentiate a mobile application from its competitors. Often times connecting to the System of Record is a necessity. This chapter discusses opportunities and challenges when enterprises build mobile applications that tap into the power of backend systems.

Enterprise mobile applications are often backed by IT services owned by the enterprise or third party services providers. Often the main mission of these mobile apps is to drive business processes that have been implemented and deployed in existing IT systems in the enterprise. This is especially true for employee-facing apps.

In today’s age, mobile devices are increasingly becoming an important platform where employees carry out their work activities. In some lines of work, mobile devices have always been a necessity. For example, in the mining industry, asset management and task scheduling for a coal mine are often done on tablet devices because the work needs to be carried out deep in the ground without the convenience of a desktop computer connected to the network. Almost all modern companies have started to build a comprehensive mobile solution for their employees in their various lines of work, as an important alternative to the desktop or laptop computers.

Many of the early pioneers in the enterprise mobility front rely on custom-built mobile devices that are preloaded with the applications. These applications operate in a fully customized and tightly controlled environment. This has changed significantly today with practices like Bring-your-own-device, also known as BYOD, where employers allow work-related activities to be carried out on the employees’ own personal devices. In a BYOD practice, it is critically important that the apps installed for work-related activities and the data that flow through these apps can coexist peacefully and safely with the personal apps and data on the same device.

These special circumstances that enterprise mobile applications operate under require certain aspects to be given special considerations. For instance, secured access is of utmost importance. From the same device the user may be living their personal life in 1 minute, and carry out business transactions in the next. Modern mobile operating systems, like iOS 7 and later, allow Virtual Private Network (VPN) to be configured on a per-app basis. This means personal applications can use the open Internet connections while enterprise applications installed from the corporate app stores use the secure tunnels provided by the corporate VPN.

Data protection is another aspect of security that companies should dedicate IT resources to, so that sensitive or confidential data do not remain on the mobile device after the business work is done, or “spill over” (for instance, through copy-and-paste) to nonconfidential communication channels like personal emails.

Enterprise mobile apps also use data stored in enterprise backend systems, or System of Records. To make the data accessible from mobile devices on public cellular networks as well as company Local Area Networks, special infrastructures such as a secure mobile gateway and data caching to enable fast access are required. Considerations should also be given to the data and service application programming interface (API) design to best cater to the different dynamics of mobile access patterns compared to tradition desk-bound accesses from computers. The average time span of mobile user sessions is much shorter and often only deal with a small portion of the data set related to a narrowly focused task.

According to a study by Boston Technology Corporation, in the next 5 years, integration of enterprise backend systems to mobile apps will represent 20% of the total IT spending on integration.¹ In that same study, 60% analyst and 60% solution providers agree that integration with legacy systems is the main obstacle to mobile implementation. No doubt, integration is essential to a successful mobile enterprise strategy, yet at the same time there are many challenges IT architects would have to face.

¹ Boston Technology Corporation, 2014. All About Mobile Integration—Stats, Facts and Methods.

All mobile applications should strive to provide a good user experience. However, depending on the kind of services and data that the applications need, what is happening under the cover for invoking services and obtaining and manipulating data can be very different from one application to another. Using the backend services and data as a way to categorize mobile applications, there are three kinds:

Thoroughbred Cloud-Based—The enterprise backend systems that these mobile applications connect to are not locked inside enterprise IT infrastructures, but are instead deployed in a public cloud. As an example, many companies use salesforce.com for their Customer Relationship Management or build custom business applications on force.com. Since these applications are deployed in salesforce.com, there are no special corporate firewalls to go through in order to access the services provided by these applications, or the data managed by them. A mobile application can connect to APIs in salesforce.com fairly easily. Most of the cloud platforms or business application platforms that exist in a public cloud support token-based authorization, such as OAuth, which makes it pretty straightforward to build mobile applications to log in to the system and gain access to the services and data, without requiring an elaborate security infrastructure.

Traditional Corporate IT—Many productivity-enhancing, employee-facing mobile applications fall into this category, where the backends are deployed behind corporate firewalls and are accessed either from the company intranet or through VPN. It is relatively simple to build a mobile application that can assume existing connectivity to the corporate network. What is more challenging is when a mobile application needs to access the corporate IT systems from the public Internet, which is typically the case with consumer-facing mobile applications for e-commerce. A lot more security infrastructure is needed to ensure only the authorized parties are able to access the services and data is protected from attacks. Fortunately, mobile applications can build on top of the existing infrastructure that have already been set up to enable web applications to conduct online e-commerce.

Mixture of Cloud-Based and On-premise Backends—A lot of mobile applications build on top of the System of Records while giving birth to a new System of Engagements. Data in the System of Engagements are not typically highly classified as those in the System of Records that reflect either trade secrets or a business’s core competency. As a result, a public cloud system is the ideal place to store this new kind of data, since it is much easier to access and cheaper to maintain (the cloud platform provider does it for you). Many mobile applications need to work with both System of Records and System of Engagements. This means they must integrate with a public cloud system and are able to securely access corporate IT systems at the same time.

Depending on the types of deployment of the backends used by a mobile application, as described above, and the types of deployment of the mobile application itself, there need to be different strategies to ensure data flows smoothly and securely from the backend to the mobile edges. In the following sections, we will go into more details on the three tiers of architecture involved in creating an enterprise mobile application solution: the backends, the integration layers, and the mobile application platform itself.

The first category is the “Enterprise Information Systems.” These systems usually run the core business operations and hold the mission-critical data that define a company’s bottom line:

• IBM Custom Information Control System (CICS®)

• IBM Information Management System (IMS™)

• Customer Relationship Management (CRM)

• Enterprise Resource Planning (ERP)

• Relational Database

These mission-critical systems make up the “System of Records.” In most enterprises, they are maintained and securely guarded by the company IT. To gain access to them often require layers of approvals. Typical data structures returned from these systems are complex and requires transformation by the integration layer. Good news is that the latest versions of these systems have all acquired ReSTful interfaces to allow much easier integration with consuming applications. For example, IBM CICS Transaction Server V4.2 and later, can install an additional Feature Pack for Mobile Extensions to acquire the ability to use JSON RPC, or ReSTful services to reach the COBOL, C/C++ or PL/I programs from mobile applications. SAP Netweaver offers interoperability with web and mobile applications since its first release in 2004.

Another important factor to consider in building integrations with these high-valued backend systems is the cost to access. Due to licensing terms typical of these commercial systems, cost is usually proportional to the volume of access. Since mobile apps tend to generate volatile usage patterns due to its convenience (it is not difficult to imagine a customer waiting at the airport constantly brings out the smartphone and checks the status of an order), directly accessing the backend system from each request sent from the mobile app is not cost-efficient. A caching strategy is needed to lighten the load on the backend system and better handle the mobile usage patterns.

The second category is systems for internal business processes such as office automation or process management. They are mainly used to boost employee productivity and improve process efficiency.

• Employee Self-Service Portal

• Business Process Management

• Enterprise Document Management

While these systems do not directly impact the company’s revenue, they are critical to reduce operation expense and improve productivity. To achieve this, it is important to provide a continuous experience between the original platform’s web user interface (UI) and the mobile app. With these mobile apps, providing a consistent UI design between the new mobile frontend and the platform’s existing web channels will increase the usability of the apps to the employees who have become used to the existing usage paradigms.

A popular approach to support a continuous experience from the desktop to mobile channels, or “multi-channel access pattern,” from a single platform is by employing responsive web designs. Responsive web design is a technique that uses CSS media queries to load different CSS rules under different browser form factors (width, orientation, etc.) to achieve optimal layout of the HTML content. Details of responsive web designs are beyond the scope of this book, but there is tons of information on this popular technique both on the Internet and in printed materials.

Many employee productivity softwares support multi-channel access by employing responsive web design techniques. For example, IBM’s WebSphere Portal has a number of mobile-enabled themes that renders individual portlets as full-screen pages when the portal page containing these portlets is loaded in a mobile browser.

Often times though, simply using responsive web design is not sufficient if the mobile channel has a high standard on the quality of user experiences. What you can do with responsive web design is limited to manipulating layout of HTML content blocks and show/hide based on the detected form factors. But the mobile applications have unique user experience patterns that are fundamentally different than desktop web applications. For example, to display a list of records, a mobile application typically uses a master-details pattern like the following (Figure 5.1):

But in a desktop browser, due to the bigger screen estate, a grid is usually the best UI to allow fast access to the information (Figure 5.2).

To achieve optimal rendering for both desktop and mobile channels, as shown in Figures 5.1 and 5.2, different widget systems need to be employed. Many JavaScript UI widget frameworks provide a widget set for the desktop rendering and a separate widget set for rendering on mobile devices. Examples include jQuery UI (desktop) versus jQuery mobile, dijit (desktop) versus dojo mobile, and ExtJS (desktop) versus Sencha Touch (mobile). This often implies that the UI will contain separate implementations for desktop browsers and mobile access. Indeed, many web sites will redirect the mobile browser to a mobile-specific implementation that is built with UI widgets designed specifically for optimal user experiences on mobile phones.

Another interesting characteristic of these internal employee-facing systems is that they often have tight coupling between the UI layer and the system API. This is an unfortunate result of the legacy software architectures from the Web 1.0 era, which still exist in the latest versions of many products in this category. As a result, building the corresponding mobile apps against these existing systems often require significant integration efforts and may involve modifying the existing backend system toward a more service-oriented architecture.

Simple Object Access Protocol (SOAP)—Heavy weight, when compared to the other protocols, has its own technology and specification stack and does not rely on other protocols. SOAP is a transport-agnostic specification and can be implemented on top of HTTP or other protocols like Java Message Service (JMS). SOAP is used widely in machine-to-machine interactions.

Representational State Transfer (ReST or REST)—Used most widely in UI-to-service integration, and increasingly used to replace SOAP as a more lightweight solution for machine-to-machine integration.

Open Data Protocol (OData)—A REST protocol that uses the AtomPub protocol to deliver the requested data. The specification also includes a description format for the service API and data models. OData is used widely in products from Microsoft and SAP. IBM WebSphere eXtreme Scale also supports OData in its REST interfaces.

eXtensible Markup Language (XML)—Still used as the wire protocol in many backend system APIs for its elaborate data type definition system.

JSON Based Remote Procedure Call (JSON-RPC)—As the name suggests, it is a procedural API that is built on remote functional calls. Unlike REST, RPC style API creates tight coupling between the consumer and the provider. Because of this, more and more JSON_RPC APIs are being converted to REST to allow improved flexibility in implementing consumer clients and service providers.

ReSTful services are preferred for integrating mobile applications with backend systems. It takes full advantage of the HTTP architecture, which is the de facto transport layer for essentially all mobile applications, and does not bring along additional semantics as does SOAP, which would complicate the application architecture. In addition, JSON is preferred over XML as the wire format of the data because of its lightweight. This is because when data is used in the UI layer, they often have static binding to the UI controls which gives them semantic meaning without needing elaborate descriptions using an XML schema. OData is a rich set of specifications that follows the REST style. As a result, consuming OData services does not require a huge set of client libraries and can be easily added to a mobile application.

Let us look at the client-side approach first. The mobile application authenticates with the target backend directly from the mobile device, either by logging in through a native login form provided by the target backend SDK, or by using an already authenticated account associated with the device. Many cloud-based backend systems support OAuth for authentication and authorization, which allows the mobile application to redirect the login flow to an OAuth provider like Google or Facebook for the user to establish a security identity through the OAuth token issued by the provider, which then can be verified by the backend systems through the corresponding OAuth provider. Other authentication and authorization mechanisms used by enterprise backend systems include basic authentication and client certificates. Basic authentication is regarded as less secure in most circumstances because it requires the user ID and password to be sent in clear texts in the request payload (although the request packet itself would typically be encrypted and sent over HTTPS). Using X.509 client certificates is more secure but it requires an elaborate Public Key Infrastructure (PKI) where client certificates that uniquely identify a user can be issued and delivered to the client mobile application through a secure process. On the other hand, the PKI can be part of the Mobile Device Management services, which will be discussed in a later section of this chapter.

Mobile operating systems like Android, iOS, and Windows Phone all allow devices to be configured with an account to be used for such purposes like automatic photo backup, email synching, or receiving messages. Some authentication providers provide mobile client SDK capabilities that use these device-identifying accounts, which have already been authenticated, to automatically establish the user identity. This makes for an improved user experience because repeated typing of user ID and password is avoided.

The main advantage of using a client-side approach for security integration with a backend system is that user identity is established and saved on the mobile device, in the form of security tokens or session cookies, so that the server supporting the mobile application does not need to keep track of the user credentials or maintain the user session with the backend on behalf of the application, which lightens the server memory consumption.

Security integration can also be accomplished with a server-side approach. First of all, almost all enterprise mobile applications have a client side, which is the application code that runs on the mobile devices, and a server side, which runs on a server platform or in a cloud. The server side provides security, data access and backend integration to support the mobile application running on the devices. Often times the server code is deployed in a mobile platform, which is sometimes called Mobile Enterprise Application Platform (MEAP) for on-premise deployment, or Mobile Backend as a Service (MBaaS) when deployed in a cloud infrastructure.

Mobile application’s server-side component would need to manage the security credentials that are used to authenticate to the target backend systems. This means when connecting to the backend services or data API, the server component will use a user account or set of user accounts that are predetermined at development time or be configured by the application administrator. This is different than the client-side approach where the user of the mobile application establishes the identity through explicit login. The server component typically saves the security credentials in an encrypted storage that is guarded by administrator privilege. When backend services are requested from the mobile application, it will perform automatic login using the stored credentials or present a client certificate that has previously been issued. The client identity that is established this way is completely separate from the user of the mobile application, in other words, the identity of the mobile application’s user does not flow through to the backend system invocations.

Finally, let us discuss Single Sign-On (SSO). There are multiple parties involved in the usage scenarios of a typical enterprise mobile application: a mobile user signs in to a mobile application, which has a database or data service for the System of Engagements, the mobile application needs to invoke services from one or more backend systems that may each use their own security provider. Without an SSO solution, the mobile application users would need to sign in multiple times whenever a different backend system is invoked. An SSO solution creates a federated identity system by using a single directory server or security provider. More complex SSO supports multiple security providers by trust-associating multiple security providers and mapping identities among the different providers.

A flow diagram of a mobile user signing in with an SSO based on a directory server, using IBM Security Access Manager and IBM Worklight is illustrated in Figure 5.3. IBM Security Access Manager provides authentication and authorization to mobile application users and devices, federated SSO, and identity mediation across different cloud service providers and web services. IBM Worklight is the MEAP where mobile application’s server-side components are deployed. Mobile applications built with IBM Worklight SDKs communicate with the IBM Worklight server for secured data access and services invocations.

The client connects to Worklight server (e.g., /flights).

1. WebSEAL, acting as the reverse proxy, caches the /flights request and responds to the client with a 200 OK status response and the WebSEAL login form.

2. The client detects the login form as a custom response, and displays the login form on the device to the user.

3. The user enters their user name and password, and clicks Login.

4. The client performs a POST operation to WebSEAL, providing the login form data.

5. WebSEAL authenticates the user.

6. If successful, WebSEAL forwards the original /flights request to the Worklight server and the configured authentication data, either the HTTP header or Lightweight Third Party Authentication (LTPA) token.

7. The Worklight server, acting as the client, retrieves the authentication data, sets the user data for the realm, and returns the successful 200 OK response to WebSEAL.

8. WebSEAL, acting as the reverse proxy, applies any path or host name filtering, and returns the response to the client.

9. The client continues to run with subsequent requests through WebSEAL (e.g., /flights).

More backend systems can be added to the SSO system as illustrated above, provided that they use the same user registry in the Lightweight Directory Access Protocol (LDAP) server. In the SSO setup, the mobile user’s identity flows to all the different systems including the mobile backend, which is the IBM Worklight server in the example above, and the backend systems.

The main advantage of WebSphere DataPower appliances is that they are easy to integrate into a network infrastructure, where they provide a software-independent configuration and simplified functionality. In addition, in development environments, some appliance virtual machines can be used to accomplish the same basic functions of the real appliances.

When used as the security layer provider, IBM WebSphere DataPower appliances can execute many critical security tasks by off-loading them from the application server (Table 5.1).

Key security-related capabilities of IBM WebSphere DataPower appliances are as follows:

• Unloading HTTPS session handling from the web server

• Acting as web application and XML firewall

• Providing authorization, authentication, and auditing (known as AAA) in a single mechanism

• Implementing an enterprise SSO function through the use of LTPA tokens

In terms of application integration and performance enhancement, IBM WebSphere DataPower appliances provide the following functions:

• Unloading XML, XSLT, and XPATH processing from the application server to the DataPower appliance and performing data transformations with better response times

• Acting as an enterprise service bus (ESB) to provide integration between different architecture layers

• Accelerating data conversion and application integration

• Providing support for transmission of specialized business-to-business message traffic between partners

When deployed in a public-facing, or Business-to-consumer, application, the XG45 appliance (or virtual appliance) is typically used in the DMZ as a reverse proxy, ensuring authorized access from the mobile applications to the internal enterprise systems. In the follow example, the DataPower appliance secures the mobile application’s server-side component that is deployed behind the corporate firewall, which in turn integrates with other enterprise backend systems. In Figure 5.4, “Worklight Server” is an example of a MEAP where the server-side component of a mobile application runs and communicates with the mobile application running on mobile devices.

When the mobile app running on the device needs to connect to the server, such as for data or services, the request is routed to the DataPower Appliance, which is in the DMZ. If the request does not have user authentication credentials associated with it, the appliance challenges the mobile app to supply the user credentials (e.g., user ID and password) and then authenticates the request against a user registry.

When the request is authenticated, the appliance injects a token into the HTTP header (identifying the user) into the request, and sends that request downstream to the MEAP server that has been configured to trust that the DataPower Appliance can assert the user’s identity. See Figure 5.5 for a typical interaction between the user, the mobile application, and the MEAP server.

For a complete list of the currently available IBM WebSphere DataPower appliances and their functions, view the product details at http://www.ibm.com/software/integration/datapower.

In certain scenarios, this is mitigated by deploying precustomized devices that are preloaded with sanctioned applications and stripping away system privileges from the user so that no customization can be done on the device and no additional applications can be installed. This means employees are carrying around a special device for work, which is dedicated to performing certain work-related tasks. For instance, airline pilots are starting to use tablet devices loaded with flight data, manuals, and aviation maps that replace the bulky paper documents. However, this practice can only be limited to certain use, often applicable to only highly specialized lines of work. To most of the enterprise use cases, BYOD offers much better return on investment and is more practical to widely deploy the enterprise mobile applications to the employees.

When an enterprise adopts a BYOD policy, to provide the ultimate convenience to their employees and save the enterprise from having to manage a large fleet of company-owned devices, it is necessary to ensure applications and enterprise data are properly managed and protected (Figure 5.6).

In general, mobile security challenges fall into these categories:

While it is impossible to prevent a mobile device from being stolen or lost, a number of security measures can be employed to minimize the impact of a stolen or lost device:

Using a complex password—Personal phones are often not protected with a password if the user does not want to bother with typing the passcode everything he or she wants to use it to check a friend’s post on social network or make phone call. While essentially all device manufacturers provide an option to secure the phone with a passcode, they are typically weak. For instance, iPhone’s default passcode is only four digits. In order to elevate the passcode strength to meet the enterprise’s security standard, a custom security profile is typically installed by an enterprise mobile application and device management software as the first line of defense against loss of corporate data. For example, when installing the mobile client application for MaaS360®, part of IBM’s MobileFirst portfolio that helps mobile IT organizations to manage mobile applications and devices, a security profile is installed which requires the phone’s passcode to be a much more complex string of alphanumeric characters.

Locking the device from being able to access the enterprise networks and discontinuing application usage—Mobile security management software often requires devices to be registered, which allows IT operations to track the user of the device and the enterprise applications installed on it. This way, the administrator can block a device from using the application backend or accessing the enterprise network. In addition, the mobile application can be developed in such a way that it always checks with the mother ship during startup for legitimacy, using factors such as the mobile application’s authenticity, presence of a secret client certificate.

Wiping data remotely—Mobile security management software must support remote data wiping. In the event that the device is lost or stolen, sensitive or confidential enterprise data can be remotely cleaned up from the device as long as a connection can be established with the device.

• Cause the loss of personal or confidential data.

• Incur additional service charges by sending premium SMS messages or initiating phone calls in the background.

• Render the device unusable.

While none of the mobile platforms provide built-in malware protections, the situation on iOS is better because of Apple’s vetting process on all AppStore submissions, which can successfully detect malware during the review process and at the same time acts as a deterring factor. On the Android side, on the other hand, malware exploitation has been steadily increasing because distribution of Android applications is open to anybody and there is no requirement to use a digital certificate that is properly signed by a Certificate Authority. An Android marketplace, including Google Play, does not typically require application submissions to be reviewed. As a result, it is much easier to publish applications with embedded malware for the Android platform. If a user is not careful and installs applications from an unknown source, the device can easily be infected by malware. According to the research report from Juniper Networks, malware on Android has increased by 400% from June 2010 to January 2011.²

² Juniper Networks, 2012. 2011 Mobile Threats Report.

Companies can significantly reduce the malware risk by adopting a similar approach to be used for both mobile devices and the desktop and laptop environment. In addition to advising employees to only download and install trusted applications, and take appropriate actions when suspicious applications are identified, a company should run antimalware software on each employee’s device to detect malware in real-time and scan the entire device periodically. This is typically part of the Mobile Device Management strategy, which will be discussed in a later part of the chapter.

The most effective anti-phishing approach helps a user recognize a fraudulent website when it is presented. Some financial institutions have deployed “site authentication” to confirm to users that they are communicating with a genuine website before they enter account credentials from either a web browser or a mobile application. Two-factor authentication is also useful to thwart phishing: First, a user enters a static password, and then a second authentication factor, such as a one-time password or a device fingerprint is dynamically generated to further authenticate the user. So even if a hacker using a phishing technique steals a user’s static password, the hacker cannot login to the genuine site without the user’s second authentication factor.

This process is defined in an authentication realm in the Worklight server’s configuration, and consists of a Challenge Handler on the client side, and an Authenticator and a Login Module on the server side (Figure 5.7).

Each time a Worklight application contacts the Worklight server, it will be challenged by the server to present a proper credential to certify its entity. A client-side component called “Challenge handler” then decides whether the current user has already been authenticated. Depending on the exact authentication mechanism used by the application, the existing authentication can be saved in the form of a session cookie or a client certificate. If one already exists, the challenge handler will present that back to the server. Otherwise, the user will be prompted to log in.

The challenge handler, running in the mobile application on the mobile device, will pass the login credentials from the user input to the server. On the server side, the authenticator collects the credentials from the client and passes them along to the login module. There are different login modules to use depending on the authentication mechanism. For instance, to use enterprise LDAP service to authenticate, use a login module for LDAP authentication. The login module will perform the actual authentication by using the credentials collected by the authenticator. Note that the login module must work in coordination with the authenticator in order to ensure the right credentials are collected from the incoming authentication request. Different authentication mechanisms require different credentials. For instance, WebSphere LTPA uses a special token embedded inside a cookie to preserve the authenticated user session. For the mobile application to work with LTPA, an LTPA-aware authenticator is needed to extract the token from the incoming request and pass that along to the login module.

Once the login module validated the user credentials, the success is acknowledged in the HTTP response. An authenticated user session is established to allow the user to access the protected server-side resources through the mobile application. The Worklight mobile authentication process described above is illustrated in Figure 5.8. For more information on the Worklight security framework, and integration with enterprise security infrastructure, visit the IBM Worklight Foundation 6.2 Information Center.

Local data storage typically needs to be encrypted to protect confidential corporate data or sensitive personal data from unauthorized access.

A typical way that data synchronization works is when the mobile application first contacts the server, a copy of the data stored in the server is downloaded and stored on the device. The application can continue to have direct contact with the server for data or start using the data in the local storage. When data is updated in the server, the user is either prompted by the application to refresh or refresh is only done when the user explicitly requests to re-synchronize. How the data is refreshed depends on how important the application has up-to-date data locally. For a pilot flight plan and operation manuals application, it is critical that the data is synchronized before the flight takes off to ensure the airport map and information on the flight route is accurate. On the other hand, an application used by miners down in a coalmine to manage the equipment has relatively stable data that do not change as often.

The tricky part of data synchronization is when the mobile application submits data back into the System of Records. When using local data store, new records may be created and saved in the data store because a direct connection is not available at the moment of the submission. Because the application may have operated on stale data, for instance, picking an equipment part number that became out of stock since the last time the data synchronization was done, synching the data stored locally back to the master database requires careful processing. This is a problem that any distributed database must address. Using a local data store essentially makes it a distributed database architecture. A technique used by many such databases, such as IBM Cloudant®, is for Update and Delete requests to include a _rev field, which is an internal counter issued by the server to mark the revision count of the record. The server uses the revision field to figure out if the submitted record from the client application has been modified since it was retrieved (at which point the internal counter was generated). Some popular enterprise MEAP and cloud-based MBaaS offer a device-local data store, as part of the client SDK that automatically synchronizes with the mobile data backend.

Distributing and managing mobile applications in an enterprise context is a crucial part of a comprehensive mobile strategy. Most of traditional application management principles apply to Mobile Application Management, such as distributing the applications to the employee’s “endpoints,” or mobile devices, rolling out updates and mandatory security patches, notifying on the employee devices of important events such as operating system upgrades. These are typically accomplished through installing an application management client on the employees’ mobile device that will enroll the user and the device, in order to allow the management server to accurately target the appropriate users and devices for specific system operations.

For Mobile Application Management, MaaS360 simplifies the lifecycle management of mobile apps for distribution and updating. The app can be private, public, and purchased. It offers an easy-to-use enterprise app catalog with full security and operational lifecycle management across mobile device platforms.

To protect against data leaks, MaaS360 offers the following apps:

• A secure mail app with email, calendar, and contacts for iOS, Android, and Windows Phone devices

• A secure browser for secure access to intranet sites and web apps, and automated compliance of content policies for iOS, Android, and Windows Phone devices

• MaaS360 Mobile Application Security as a mobile application container with full operational and security management to protect against data leaks for iOS and Android devices

Enabling a mobile application for secure management can be achieved either at application development time, by using special libraries or SDKs that enhances the security of normal system operations, or by rebuilding the application during deployment time and replacing certain system libraries with special libraries that provide enhanced security. The latter approach is often referred to as “application wrapping.” Mobile application management products that support application wrapping typically allows an administrator to upload an already built mobile application binary (.ipa for iOS or .apk for Android) to an administration port, and select the list of security policies to enforce on the application, then kick off a special build that replaces the relevant libraries within the mobile application binary.

The application wrapping technique allows the enterprise to centralize the control of mobile application behaviors according to the corporate security policies, without having to ask each application development team to follow the same practices to develop with the necessary security libraries. On the other hand, typically using the SDK, development teams have more flexibility on the behaviors of the application in order to build the best user experiences. All of the security requirements can be met by using either technique. For example, file I/O can be enhanced to require stronger encryption than provided by the mobile operating system by default, such as the Federal Information Processing Standard (FIPS) 140-2. Network communications can be intercepted and redirected through a corporate VPN tunnel to protect the data in transit. Cut-and-paste from certain applications that contain sensitive information, such as a financial analytical services app, can be disabled by applying encryption to the clipboard, resulting in garbled content being pasted into an unmanaged application that does not have the right security key to decrypt the clipboard content.

Let us first evaluate using adapters that are custom-made for one or more mobile applications.

Why are adapters a good idea for mobile applications consuming enterprise backend system services? First of all, adapter is not a new concept. Many existing software solutions that involve multiple systems often employee adapters for integration purposes and keeping the impact on the whole solution to minimum one or more systems are changed. In other words, adapters promote decoupled architectures. In Java Enterprise Edition (Java EE), Enterprise JavaBeans session beans are one kind of adapters.

There are more reasons to use adapters in an enterprise mobile application. In today’s complex IT systems, it is rarely the case that the backend APIs needed by the mobile application are directly consumable. Maybe the APIs were designed to support a wide-range of usage patterns but the mobile app only needs to use a small subset, which as a result requires the input parameters and return values to be simplified to improve efficiency. Adapters can optimize the invocations to the backend APIs and simplify the calls from inside the mobile applications, which results in faster network communication and lower bandwidth consumption.

Or, maybe the protocols are geared toward machine-to-machine processing and emphasize grammatical accuracy, like XML, but are overkill for UI-to-machine communications. For example, most UI applications provide client-side validations to ensure user input conform to the data model on the server side. However, if XML is used to transfer data, when the server processes the data using an XML parsing library, an XML schema is often required to do the transformation from the markup content to internal data models. In this process, the user input is validated again, using the XML schema. In most cases, the validation on the server side is not needed but is unavoidable with XML.

In almost all mobile applications, JSON is the preferred data transfer format because of its compactness and fast parsing. Adapters can do the protocol transformation between JSON, which is needed by the client side, and other protocols supported by the backend APIs such as XML (including SOAP).

In IBM Worklight, which is the mobile application platform for IBM’s MobileFirst portfolio, adapter is a standard architecture component for developing mobile applications. Worklight Adapters connect to enterprise backend systems and deliver data to and from mobile applications. Worklight Adapters also perform server-side logic that is specific to the mobile applications they serve.

Worklight Adapters are deployed to the Worklight server and can be access from any mobile applications deployed to the same Worklight server (Figure 5.9).

Worklight Adapters are developed in JavaScript. To assist in transforming XML data from the backend APIs to JSON, Worklight Adapters support XSL that the developer can supply to make it easier to parse and process hierarchical data.

When adapters communicate with the backend systems, they can assume the security identity of a predetermined user account, or the user account of the incoming request from the mobile application. The former is called “run as server.” The latter is called “run as user.” Which connection policy to use depends on what options the target backend system supports and the access privilege required by the mobile application. Another factor to consider is billing options. A backend system may charge per user account. You may need to use “run as user” if the users of the applications are expected to shoulder the cost of utilizing the backend system’s services. Or if this cost can be covered by a functional account that serves all users, then select “run as server” and configure the adapter with that functional account.

What about using commercial solutions that are ready to use with minimal configurations to support a variety of enterprise backend systems?

WebSphere Cast Iron Live is the cloud integration-as-a- service solution. Using a “develop once, deploy anywhere” approach, WebSphere Cast Iron Live is ideal for customers with a majority of their applications based in the cloud and with no infrastructure on premise. The offering follows the same model as Software-as-a-Service (SaaS) or On Demand services. SaaS approaches run a company’s business applications through a network on a remote host and look and operate exactly as if they were running on the company’s own systems. WebSphere Cast Iron Live runs under the same model, meaning companies who integrate using this product can integrate their SaaS and web-based applications in real time.

WebSphere DataPower Cast Iron Appliance XH40 is a stand-alone, self-contained hardware offering. It is the preferable option for customers with a majority of applications based on-premise who need a standards-based solution and who find software-based integration solutions to be too complex. It comes with all of the required programming on-board for a particular integration project. The device is called an “appliance” because it has the same self-contained/dedicated function characteristic as most appliances, like a network router. They look like any other rack-mounted box, but are dedicated to one important task: integrating multiple on-premise or SaaS applications.

IBM WebSphere Cast Iron Hypervisor Edition is a virtual appliance for service integration. It provides connectivity to a variety of cloud-based and on-premises applications, databases, web services, messaging systems, and other endpoints. In addition to predefined endpoint connectors, IBM WebSphere Cast Iron Hypervisor Edition includes templates that enable access to other endpoints such as Google Analytics, Microsoft Azure Servicebus, or Oracle CRM on Demand.

IBM WebSphere Cast Iron Hypervisor Edition uses a configuration approach in which integration projects are configured instead of programmed. With a configuration approach, mobile applications can be connected to backend systems without any help from a developer. Instead, you build the needed integration flows using a graphical development environment in WebSphere Cast Iron Studio.

Each integration project consists of one or more orchestrations, each of which describes a specific set of activities that define the flow of data, including access to backend systems and data transformations. Mobile applications can use an IBM Worklight Cast Iron adapter to perform the activities defined in an orchestration.

Transforming data from its original format to another format can be done using a simple drag-and-drop method in the WebSphere Cast Iron Studio graphical mapping editor, which is shown in Figure 5.10. There is no need to understand all supported data formats because the data transformations are done visually using the mapping editor.

Business logic rules also can be set up using the graphical mapping editor. Because it is a WYSIWYG (what you see is what you get) interface, business users can participate in an integration project without any specific IT skills.

For administration, WebSphere Cast Iron Hypervisor Edition provides a web-based console to monitor the data flow, handle exceptions in the data flow, and provide proactive alerts regarding data and connectivity errors. The console also provides easy access to key performance indicators.

IBM WebSphere Cast Iron provides a secure environment with capabilities to easily and rapidly assemble and publish useful business services. Reusing these existing business services (and their existing infrastructure) can reduce a new application’s time-to-market. A company can also offer these business services to other companies to open new market opportunities.

More information about IBM WebSphere Cast Iron can be found at http://www.ibm.com/software/integration/cast-iron-cloud-integration/features.

When innovation user experience design on the device side is paired with highly available, speedy, and secure backend services, killer mobile applications will emerge and capture the precious user attentions. The best mobile solutions do not stand alone, but instead work seamlessly with the other UI channels and provide a continuous user experience, no matter where the users are.