Mobile Application Architecture Initiative

Steve WheatChief IT Architect

Agenda

• Goals of the Mobile Application Architecture Initiative

• Method of Achieving the Goals of the Initiative• Progress and Overview of Current

Recommendations• This presentation and links to everything

referenced here are available athttp://arch.it.emory.edu

Goals

• Design and develop a number of mobile applications• Write a mobile application reference guide similar in scope

and detail to guides prepared for EAI/SOA and web application frameworks

• Review, expand and amend the reference guide with review and input from units that develop, support, and implement mobile applications

• Implement the recommendations of the reference guide in the architecture review checklists and technical design review processes as appropriate

Mobile Applications

• Over the past two years we have designed, developed, and/or deployed and integrated the following mobile applications:• BioCatalogue Mobile• EdUnify Mobile• Emory Mobile• PKU Mobile*• WebEase Mobile• Mass Transfusion Protocol (MTP) Mobile*• WebEase Mobile for Kids*

* Design stage only, no funding yet for implementation and deployment

Mobile Application Reference Guide

• Like the EAI/SOA and web application reference guides it provides both a high-level overview and low-level detail (microarchitectures) for developing mobile applications

• Serves as both an instructional guide and architecture compliance reference

• Implemented as a wiki so everyone who uses it may comment, propose and collaborate on new sections

• Intended to facilitate communication in detail. The engineering of modern software requires written documentation and schematics to facilitate intelligent discussion

Review, Expand, Amend…

• The outline of these guides follow high-level scenarios of the types of projects we undertake. For example:– Build a mobile application– Engage consultants to build a mobile application– Implement/customize a vended mobile application– Store and manage data collected by existing mobile applications– Expose Emory data to existing mobile applications

• We’ll address most of these major scenarios, but there may be others identified in the review

• The low-level details require extensive review of the goals of each microarchitecture and code samples from reference implementations and actual projects

Implement Recommended Architecture

• Train technical leads and reviewers in the details of the architecture described in the reference guide. Most should already be well acquainted with the approach from reading, commenting, and proposing new sections to the guide on the wiki

• Add clear guidelines to implement these architectures to the technical design, architecture, and security review templates as appropriate

HALS

WebEase

Service

Proxy

Service Routing

Service

Sonic Cluster

Logging

ServiceWeb Ease

App

Web Ease WS

Mobile App Architecture Overview

ESB Cluster

Web

AppWeb

ServiceFacade

HIPAA Audit

Logging Se

rvice

Web

App’s

ESB

Service

Proxy

Service Routing

Service

JMS Provider Cluster

Logging

Service

https

https

ssl

ssl

AS Cluster

client certauth

BrowserClients

Native iOS and AndroidClients

Certificate

Service

Key Mgmt.

Service

Progress and Recommendations to Date (1)

• Mobile application architecture relies heavily on the existing EAI/SOA and web application architectures

• Mobile applications must access application logic and data through a service layer, which also implements additional security---SOA is no longer optional

• OIT’s Google Web Toolkit web application frameworks allow us to provide alternative views for mobile devices within the same framework we use to create desktop web views. Because almost all mobile applications have a need for desktop interfaces, developing mobile web apps using this common framework should be our default approach

Progress and Recommendations to Date (2)

• There are use cases that trigger the need for native iOS and Android mobile applications that are not readily accommodated with mobile web applications. These include the need for:– Continuous background processing or collection of data (i.e.

connecting seizure motion data from an accelerometer)– significant amounts of frequent or rapid data entry (i.e. entering

detailed diet information throughout each day)– Unreliable or intermittent network connectivity (i.e. running a

diagnostic algorithm in the ER at Grady)

Progress and Recommendations to Date (3)

• Native iOS and Android applications bring with them the need for additional microarchitectures and security considerations, especially for applications subject to HIPAA compliance policies. These architectures include the need for:

– Message object API to represent application data and logic for iOS and Android– Web service client generator for iOS and Android to generate web service clients for each web

service with which applications must interact and to implement access of server side resources in a consistent and uniform manner

– Client authentication mechanism to authenticate the distributed client application– Client authentication mechanism to authenticate the device deployment of the client

application – User authentication mechanism to authenticate the user of the client– Data encryption for persistent data stored on the mobile device– Distribution mechanism for internal mobile applications (apps that are not distributed through

publicly accessible app stores)

Progress and Recommendations to Date (4)

• In each of these areas we’ve implemented or are working on the following:– Objective C Message Object API generator comparable to MOA gen in Java– Web service client generator for Objective C similar to Apache Axis wsdl2java

for Java– Client certificate authentication for all mobile applications we distribute– Replacing the distribution certificate with a deployment certificate upon first

use (this and the preceding item require certificate generation and management ESB/web services)

– User authentication ESB/web service– Data encryption framework for application data on the mobile device (requires

key management ESB/web services)– Over the air internal mobile application distribution available at

https://dev.app.emory.edu/mobile/[application_name]

Status and Documentation

• All of these findings and recommendations are appearing in one of two wiki spaces:– Google Web Toolkit Reference Guide– Mobile Application Architecture Reference Guide

• GWT Guide is already complete and vetted with more details being added for mobile web app interfaces

• Mobile App Reference Guide will be ready for in depth discussion and review by Summer 2013 after the release of a couple more mobile apps

The End

Questions?