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.
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:
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
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
- Remote Data Access
- Decouple View from Application Model (MVC pattern)
- Dependency Management
- Exception Handling
- Require.js – AMD based module organization and library dependency management
- Jquery – Document Object Model(DOM) access and manipulation
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:
— David Pitt, email@example.com