Part 1 of the series on “Architecture for Multi-Device Applications” focussed on the bare-bore design.

In Part 2, we look at high-level implementation structure – a slightly more detailed version of the design discussed in Part 1, before we start opening the individual boxes.

One of the key aspects that we discussed in Part 1 was the separation between the “Application Server” and “Web Server” layer and argued that most of the applications that we come across in real world, daily life, don’t really separate them… or rather we find them difficult to separate because of the choices that we have or we are “taught” in our life.

The diagram below summarizes what I am talking about…

Oh! Damn… doesn’t this diagram look horribly close to the earlier one? Where’s the difference / value-add?

Ok…. I heard you. As I said, this is still a high-level diagram but let’s look at now the options available within each box:

1. Application Consumption: Desktop Browser, Mobile / Tablet (Browser or Wrapped Browser), Internet TV, Mobile/Tablet Native applications.
2. User Interface Servers: Also known as the frontend servers and preferably generates cross-browser / cross-device HTML5 / CSS3 based user interface, unless it’s a native application for desktops / mobiles.
3. Biz-Logic Access Layer: Also known as the backend servers. They provide controlled access (read: authentication / authorization) to the data from the store (as is or processed). The access, preferably, is RESTful – this, however, is not mandatory. This layer, typically, is very thin – parses the incoming data, passes on to the biz-logic layer and serves back the response.
4. Biz-Logic Layer: Typically, they are no different than the Biz-Logic Access Layer in physical deployment topology. However, in terms of implementation, it may be libraries that are consumed by the backend (access) servers.
5. NoSQL Access: I could have just called the data-tier as persistence layer but I strongly choose NoSQL because that where you really are able to get the scale. If you are writing an otherwise application, replace this box with data-access layer.
6. NoSQL Store: The actual store of the data.
7. Client-side Data Cache: You may need that for long-activities or offline access or otherwise.
8. External Modules (Frontend): If your application provides UI-integration with other servers (say, Facebook / Twitter / Pinterest Social Integration or otherwise).
9. Server-side Data Cache: I don’t think there is any need to talk about its usefulness. Having said that, you may not always use it.
10. External Systems (Backend): For any API-based integration with 3rd party systems (say, Facebook / Twitter data access and processing that may require application secret key etc)

I hope the structure is now clear. In subsequent parts, we shall dissect open each box and explore:

1. What is it all about in detail
2. External forces or uncontrolled parameters (e.g.: Browser etc)
3. The options available
4. Comparative study of the options – to decide when to use what

Keep watching…