Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mobile Application Architecture Initiative Steve Wheat Chief IT Architect.

Similar presentations

Presentation on theme: "Mobile Application Architecture Initiative Steve Wheat Chief IT Architect."— Presentation transcript:

1 Mobile Application Architecture Initiative Steve Wheat Chief IT Architect

2 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 at

3 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

4 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

5 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

6 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 Well 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

7 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

8 HALS WebEase Service Proxy Service Routing Service Sonic Cluster Logging Service We b Eas e Ap p We b Eas e Ap p We b Eas e WS Mobile App Architecture Overview We b Ap p We b Ap p Web Servi ce Faca de Web Servi ce Faca de HIPAA Audit Logging Service Web Apps ESB Service Proxy Service Routing Service JMS Provider Cluster Logging Service https ssl client cert auth Certificate Service Key Mgmt. Service

9 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 OITs 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

10 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)

11 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)

12 Progress and Recommendations to Date (4) In each of these areas weve 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[application_name]

13 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

14 The End Questions?

Download ppt "Mobile Application Architecture Initiative Steve Wheat Chief IT Architect."

Similar presentations

Ads by Google