Mobile HTML5 Enterprise Application Architecture

David Pitt Architecture, HTML5, JavaScript, Mobile, Tutorial 10 Comments

If you’re thinking that you can prevent end-user demand for mobility, just remember this: when PCs were first introduced, IT attempted to hold them at bay. How did that work out? Mobile device proliferation is causing (some say forcing) IT departments to change. They must now support mobile devices, which further extends to IT having to develop mobile-friendly applications. Simply accessing existing corporate applications via a mobile browser just won’t fly.

Delivering a rich user interface for a mobile application can be either done natively or using HTML5 with Javascript. Native applications can provide a rich user experience, however it can be time-consuming and expensive to build native applications for multiple device operating systems. HTML5 with Javascript has opened the door for device-independent user interfaces. This means that user interfaces can be created using Javascript component libraries that render interactive user interface widgets using HTML5 elements. HTML5 has many new features that support mobility and rich user interface development. However, exploring these features is not the intent of this article. Instead, this article will concentrate on the application architecture required to develop HTML5-based applications.

Current Thin Browser Application Architecture

Consider current web-based application architectures that many enterprise have developed using the .NET and Java EE technology stacks. There are many deviations of this, but this is arguably a common architecture pattern:

6:29 thin-browser-application-architecture

This application architecture puts all elements server-side. Dynamic HTML is produced from server-side software and user interaction and dynamic user interface transition is handled in a server request/response mechanism. HTTP traffic consists of server-side generated HTML/browser elements. AJAX calls and data sources are accessed and merged into the resulting HTML tags returned to the browser for display. Lots of bandwidth is consumed with user interface HTML elements, screen refreshes and latency, hindering rich client behavior. While this may work for desktop browsers, mobile based browsers have less processing power and bandwidth, causing mobile to struggle.

Mobile Rich Client Browser-based Application Architecture

HTML5 directives and features, along with the mature Javascript libraries, allow very rich user interfaces to be defined within a browser context. Previously, plug-in technologies such as Java applets or Flash/Flex were used to deliver robust application type interfaces. Now, this can be accomplished with HTML/Javascript elements. This leads to an application architecture where the user interface elements and supporting model exists on the client (browser) and the server is responsible for headless data access for the application. This is shown in the diagram below:6.29.12 mobile-rich-client-browser-based-application-architecture

See Also:  Placing React in Timeout with Material-UI

Client/Server? Not really.

If you’re thinking that we’ve just gone back in time to a client/server architecture, that’s partially true. However, the primary difference is that the application is not permanently resident on the client. The browser and web provide a standardized way to deploy applications. In the client-server days before the web, client applications were installed on the workstation and updates were performed by various non-standard means. Connectivity to data sources was configured on the workstation, increasing the support burden.

The universal adoption of web standards opens the door for rich client implementations to be introduced in a three-tier manner, but obtain the benefits of rich client/server experience.

Applications, Not Web Sites

Initially HTML and browsers were intended for website development. However it soon was modified to support user interaction, and the wide acceptance of the web made it a platform to deliver full-blown applications, not just brochure-ware. As stated earlier, browser plug-in technology (flex, applet) filled the role of rich user interface requirements, but there was always a problem with keeping plug-in versions and capabilities in sync with browser versions and features. Browser and HTML standards, as well as the optimization of Javascript interpreters are now at the point in which rich interactive applications can reside on the client.

JavaScript Application Architecture

Javascript was never really intended to be a general programming language. However, its dynamic and object oriented-nature, along with its usefulness in manipulating the HTML Document Object Model (DOM), has made it the primary way to build dynamic HTML applications. However, the language does not provide modularization constructs that available to more general purpose languages such as Java or C#. Additionally, it being a weakly typed dynamic language that allows closures and the ability to treat code blocks as datatypes provides a lot of programming flexibility. But, that can lead to unmaintainable code. Therefore, rigor must be applied to Javascript-based applications. Here’s a list of some generalized mechanisms that need to be put into place:

  • Navigation
  • Remote Data Access
  • Authentication/Authorization
  • Decouple View from Application Model (MVC pattern)
  • Modularization/Packaging
  • Dependency Management
  • Logging/Tracing
  • Exception Handling
See Also:  Mockups with MockOla

In the Java world, frameworks exist to help support a layered application architecture. Likewise frameworks are available in the Javascript world to also help support a layered application architecture. Although not as numerous, here is a list of frameworks that we have experience with that help support architecture attributes.

Client Frameworks

  • Backbone.js – Javascript MVC/Navigation framework
  • Require.js – AMD based module organization and library dependency management
  • _Underscore.js – Provide functional programming features to Javascript
  • Jquery – Document Object Model(DOM) access and manipulation
  • Jquery Mobile – Mobile HTML5 Javascript Components

Server Side Java EE Frameworks (These could be replaced with comparable .NET frameworks)

  • khsSherpa – Remote Java Object/JSON Data Access framework
  • Spring Core – Dependency Injection
  • Spring Security – Role Based Security Framework
  • Hibernate – Object Relational Mapping Framework

Here’s a picture of the application topology:

6.29.12 html5-application-architecture

For a more in-depth look at HTML5/JavaScript Mobile Application Architecture, make sure to download Keyhole’s informational White Paper: HTML5 Application Architecture.

— David Pitt, [email protected]

Get The Latest Posts By Email

Enter your email address to subscribe to the Keyhole dev blog and receive notifications of new posts by email.

Comments 10

  1. I have been working in .net technologies for 10-13 years. i read your article and loved one. it is really information to me.

    About the archicture for Mobile Web application. i would like to discuss the approach with you and know your thoughts on that. Mobile devices does not have powerful browsers and to reduce the to-fro requests and to reduce network trips. i would like to share my thoughts on that.

    1. mobile rich user interface should be developed using HTML5 + CSS3 and Javascript.
    2. to establish relation with server, to store and retrieve data from DB, there should be Web services, it means all business logic should be in web service. device browser will send request by calling web service and based on that data will be processed and stored in to DB.

    the advantage would be, we can reuse the web service for other purpose as well.

    share your thoughts on this.

    1. Thanks for the comment, and yes I agree with your point there should be some kind of server endpoint receiving these requests. I would say that in some cases a SOAP or even XML restful web service might be a little heavy for a browser/javascript client. JSON payloads are efficiently/automatically marshaled by Javascript and will utilize less bandwidth an XML based service. Of source this assumes a javascript client to consumer. A web service endpoint would be more appropriate if other consumers of the endpoint are possible, but is a web server/SOA type discussion. Regarding your HTML5 point I agree in the case of building enterprise apps, building native applications can be costly to build and maintain. However, there are reasons that we have built native applications, i.e. accessing device api’s, large local storage requirements, sometimes the native UI widget set provides the best user experience. Hope this helps. Thanks, David

      1. Thanks David for your valuable inputs.

        So we can say if smart phone applications should use JSON as they are not having powerful browsers where else, the enterprise applications which are being used on desktop browsers and need to maintain the session over each call then Web service would be better approach.

  2. Pingback: 10 Tech Stories To Read This Week – July 17, 2012 » iRomin

  3. I would really want that local client storage becomes better. You need a proper framework of hybrid data storage – local data and data on cloud. And local data should be robust. It should not be limited by size. Chrome installed apps seems to be going in that direction but these are early days.

  4. Hi David. First I want to thank you for this wonderfull article. I’ll start to build an application and I’d like to have your opnion. I’ve built a desktop application using Flex and Java, but now I need build a mobile app and I’m thinking in HTML5 but I don’t know which server side technology I should use. I’d like to reuse the Java Server side that I’ve already have. What do you suggest for me to communicate my client (HTML5) with my server (JAVA)?

    Thanks again! Best regards!

    1. Wesley,

      Thanks for the comment. We have some customers that are also moving from a flex UI, and we are using java server side endpoints to marshall JSON back and forth. We chose JSON over XML for efficiency. We’ve build an open source framework specifically for this. It allows a standard Java app server to support remote Java/JSON/endpoints. It has security mechanisms and supports a restful type url’s. It can be found at Or, you could roll your own approach using servlet(s) and a JSON serializing framework such as Jackson. Google also has JSON framework for java. Another approach would be to adapt an existing server side MVC framework such as Spring MVC to support server side requests/responses.

      Hope this helps.

  5. This is a very useful article and I was hoping to get some much needed direction for an upcoming mobile dev project.
    However, a couple of issues dented the effectiveness:
    – Arch Images are not rendering
    – This is from 2012, any updates (4 tier architectures, importance of Front End Middlewares etc.) to provide additional insights into newer arch would be highly appreciated.

    1. Hi Dhananjay,

      Thank you for your comment! Really glad to hear that you have found it useful.

      We appreciate you letting us know about the image rendering issue – it has been fixed and the links have been updated.

      You might be interested to read this white paper on the topic with a bit more detail: Also a more recent post includes

      Lauren @ Keyhole

Leave a Reply to Ashish Chauhan Cancel reply