Skip to content
June 29, 2012 / Keyhole Software

Mobile HTML5 Enterprise Application Architecture

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 JEE technology stacks. There are many deviations of this, but this is arguably a common architecture pattern:

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:

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

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 JEE 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:

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

— David Pitt,


Leave a Comment
  1. Ashish Chauhan / Jul 13 2012 11:39

    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.

    • David / Jul 13 2012 12:15

      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

      • Ashish Chauhan / Jul 15 2012 11:00

        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. Vishal Kumar Singh / Jul 22 2012 09:29

    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.

    • David / Jul 23 2012 08:17

      I agree, my hope is that the W3C websql spec comes out of it’s dormancy.

  3. Wesley Diniz / Jul 26 2012 08:09

    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!

    • David / Jul 26 2012 15:20


      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.


  1. 10 Tech Stories To Read This Week – July 17, 2012 » iRomin

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: