MOBILE APP DEVELOPMENT LEAPS FORWARD

(1)

DEVELOPMENT

(2)

Home

Developers get into BaaS, mobile APIs for new opportunities How to make design choices as mobile and IoT applications collide

ackend as a

Service (BaaS) is making

waves in the mobile application

develop-ment space. In this e-guide, learn how you

can implement BaaS and how it functions

similarly to Platform as a Service (PaaS). Additionally, learn how

incorporating the Internet of Things (IoT) with mobile worker

sup-port can enhance business productivity.

(3)

Home

DEVELOPERS GET INTO BAAS, MOBILE APIS FOR NEW

OPPORTUNITIES

Tom Nolle, CIMI Corporation

A new development in the application programming interface (API) market, Backend as a Service (BaaS), offers devel opers a whole new dimension of op-portunity: cloud services to build the mobile applications of the future.

Mobility, mobile broadband and mobile apps are transforming the Inter-net and the way people communicate and use information. For developers, the mobile app represents an enormous, lucrative new market. From a business perspective, each of the mobile platforms has its own benefits and limita tions. Each also has its technical framework -- its own APIs. Mobile develop ment platform APIs generally fall into two categories: platform APIs related to the mobile device’s own operating system and middleware, and service APIs re-lated to the access of Web-hosted material.

The new opportunity in APIs is Backend as a Service, an extension of the service API model. The goal of BaaS is to convert common and useful elements of mobile application logic -- storage, identity management, social network

(4)

Home

integration, photo enhancing -- into representational state transfer (REST) Web services that the application invokes as needed, making these services “back ends” to mobile apps.

As a concept, BaaS is similar to Software as a Service (SaaS) and Plat form as a Service (PaaS): It offers functionality as a Web service. With SaaS, what’s offered is an application or application component. Salesforce.com’s CRM is a good example. PaaS offers a collection of services designed to pres ent a com-plete virtual operating system; Microsoft’s Windows Azure is the best-known PaaS example. BaaS is somewhere in between; it offers PaaS-like features, but not as a complete programming platform. Like SaaS, those features might perform business functions oriented to vertical markets or functionalities that can be used across industries. In all cases, though, BaaS aims to enhance mobile development.

IMPLEMENTING BAAS

Success with BaaS requires a targeted business case and careful implementa-tion to support mobile development practices. Most BaaS deployments today are horizontal -- they cover a variety of markets -- and deal with well-known is-sues such as social network integration. The problem with these types of BaaS

(5)

Home

implementations is that they are so obvious that competition is inevitable, and so basic that differentiation is difficult. For example, it’s likely that major cloud providers will move into BaaS services related to storage and iden tity, and social network companies will offer social network BaaS integration. Vertical markets, where a developer already has skills, contacts and software products, are useful places to look into for BaaS opportunity. In horizontal mar kets, data analysis and reduction tools, or forecasting and projection tools, are good can-didates for BaaS.

Technically, the key issue for BaaS is preserving the dominant RESTful Web service model of interface. These in terfaces appear as a simple PUT/GET transactional model that doesn’t re main in a processing state between calls. Most of the major PUT/GET giants have exposed their own service APIs as RESTful interfaces that receive and re spond using XML data structures. XML handling can be a chore, however, and it’s helpful to either accept a simpler data structure or provide programming logic to use the interface as a reusable func-tion in each of the target mobile devices.

Creating a BaaS service with the correct level of functional granularity is also important. Mobile users typically expect a quick response to a request, and there are interface timing issues that make it unadvisable to turn a com plex

(6)

Home

function with a long execution time into a single service. Since RESTful inter-faces are expected to be stateless, care is required in turning a complex func-tion into a series of elements that can be used independently, but can funcfunc-tion together when needed. Each request must stand on its own, and data from the response to a given request, if needed later, must be stored in the device and returned or maintained and updated by the service.

PASSING AS PAAS

Perhaps the most significant aspect of BaaS, from the developer’s perspec tive, is the relationship with PaaS. Any developer who has reviewed the APIs for search or social network giants, or for cloud management, knows that mul tiple APIs typically form an ecosystem that, if it grows large enough, can ap proach the functionality of a platform, as in PaaS. A few disconnected BaaS APIs are less compelling than, for example, an entire BaaS ecosystem aimed at support-ing mobile-social network collaboration for enterprises. Popular open source blogging or chat room tools, for instance, could be built on uni fied communica-tions and collaboration, augmented with APIs to create voice and video calls.

BaaS will lead to a systematized view of background services for mobile de-velopment, which is for all practical purposes a mobile-driven PaaS plat form.

(7)

Home

Developers, operators and enterprises need to think about this evolu tion -- be-cause a cooperative and symbiotic collection of BaaS tools are more valuable to developers and consumers than individual APIs could ever be. The BaaS movement could be a catalyst for moving developer focus from de vices to the cloud -- and that means faster service and increased competition among hand-set vendors. But BaaS, like any cloud trend, is in the early stages, and there’s a whole mobile world out there.

(8)

Home

HOW TO MAKE DESIGN CHOICES AS MOBILE AND IOT

APPLICATIONS COLLIDE

Tom Nolle, CIMI Corporation

The Internet of Things has been getting considerable coverage, causing com-panies to explore ways IoT concepts can enhance productivity. Often, this research leads to one specific IoT model that shows promise: combining IoT with mobile worker support. Architects and planners charged with design-ing for this model must understand what the mobile/IoT model really means, address how adding IoT changes the equation in mobile empowerment, and define their own design pattern to represent how mobile/IoT applications will be handled going forward.

Most legitimate IoT applications involve interaction between users and what could be called a sensor and control network (SCN). In process control applications, the SCN is a machine-to-machine, or M2M, network that uses sensor information to drive changes in material handling or processing. These applications might use mobile technology as a means of communicating with sensors, but they don’t force major changes in application design as normal

(9)

Home

industrial control applications would.

Mobile and IoT applications collide in applications where a worker is vi-sualized as moving through a sensor and control space and interacting with elements. If their full potential is to be realized, these applications require very different design concepts than normal mobile or IoT applications do.

TAKING THE FIRST STEP

The first step in designing mobile/IoT applications is to ensure enterprise ar-chitecture process models are up to date and reflect the business information flows and activity sequences the mobile/IoT application will generate. Many early attempts at harnessing the benefits of mobile/IoT failed because those benefits weren’t linked to specific enterprise processes and flows, and so nei-ther could be validated or supported.

The second step in mobile/IoT application design is understanding what’s in the SCN space. Is the application one where a worker gets information from sensors, one where a worker activates networked control elements to perform a specific task, or both? The answer will determine the best starting point for new application design -- is it contextual in nature or registration and activation?

(10)

Home

that information can be viewed as enhancing the notion of context that forms the underpinning of all mobile empowerment applications. This approach embodies two broad alternative models: the extended-senses model and the sensor-driven model.

Extended-senses models use IoT sensors to augment what a worker can know about the current context -- the point of activity. Generally, a worker’s location establishes what IoT sensor information is available nearby, and that information is collected automatically into the worker’s contextual inventory, to be processed as any context data would be. This is an easy model to imple-ment because it extends, but doesn’t change, the application model for mobile empowerment.

In a sensor-driven model, the application identifies a situation that needs handling based on sensor information, and then alerts and perhaps dispatches the worker to the right spot. This model differs sharply from normal mobility applications because the worker is driven by the application rather than driving it. The context of the job is set by the conditions at the point where the worker is expected to be active, and the goal is getting the worker there.

(11)

Home

A KEY INGREDIENT

The key ingredient in this sensor-driven model is identifying an alert condi-tion in the first place. If a sensor and control network is already being used for process control, facilities monitoring and so on, it might be possible to gener-ate a trigger for IoT/mobile activity from the current process or monitoring application. Taking that approach is wise because it reduces the risk of loading down sensors or sensor networks with additional traffic. If it’s not possible to piggyback on current process or monitoring applications, sensor information will need to be analyzed.

If possible, avoid reading sensors from a new application. Most sensor and control applications store sensor data in a database regularly. By running ana-lytics processes on stored data, it might be easier to spot unusual conditions. For example, temperature and humidity changes are easier to view as a trend line because any sudden change would be unusual and likely warrant a visit from a technician. Using DBMS-based analytics as the source of IoT context also will reduce the complexity of finding and reading relevant sensors.

The final point is the importance of consistency. Virtually every user who has looked at the mobile/IoT combination will admit that many applica-tions would fit that description, but few represent the low-hanging fruit that

(12)

Home

typically drive projects in a new technology area. A major risk is that each ap-plication could produce its own software based on a unique approach, and that would compromise application agility and component reuse. It could also cre-ate operational problems if the worker empowerment element varied between applications.

Software architects and developers know the accepted way to address these risks is the creation of a design pattern, a template-like approach to a problem that can be implemented as needed. For applications blending mobility and IoT, a design pattern would likely be needed for both the extended-senses and sensor-driven models. It’s possible to conceptualize a design pattern that ac-cepted a condition set that represents testable sensor conditions and an op-tional worker location, and returned a set of values representing sensor results. It can be tempting to jump in to API design too quickly. Be sure to have enough exposure to the complete range of mobile/IoT applications, at least at the business process level, before committing to specific componentization and API design. Taking the intermediate step of developing one or more formal design patterns will ensure the API transition is made with a broad knowledge of the needs and opportunities the union of mobility and IoT can bring.

(13)

Home

FREE RESOURCES FOR TECHNOLOGY PROFESSIONALS

TechTarget publishes targeted technology media that address your need for information and resources for researching prod-ucts, developing strategy and making cost-effective purchase decisions. Our network of technology-specific Web sites gives you access to industry experts, independent content and analy-sis and the Web’s largest library of vendor-provided white pa-pers, webcasts, podcasts, videos, virtual trade shows, research reports and more —drawing on the rich R&D resources of technology providers to address market trends, challenges and solutions. Our live events and virtual seminars give you ac-cess to vendor neutral, expert commentary and advice on the issues and challenges you face daily. Our social community IT Knowledge Exchange allows you to share real world information in real time with peers and experts.

WHAT MAKES TECHTARGET UNIQUE?

TechTarget is squarely focused on the enterprise IT space. Our team of editors and net-work of industry experts provide the richest, most relevant content to IT professionals and management. We leverage the immediacy of the Web, the networking and face-to-face op-portunities of events and virtual events, and the ability to interact with peers—all to create compelling and actionable information for enterprise IT professionals across all industries and markets.