The Architecture of a Rich Internet Application

Whether you are using Flex, Ajax, Silverlight, JavaFx, or some other RIA technology, the basic architecture is going to be pretty similar… In most cases you will typically have have a stateful client application and a separate services layer on the backend. It is important to understand this differentiation, and to understand that this plays a huge role in how you design and build your applications.
Architecture.jpg

RIA lends itself more to client-server development, rather than tradition web development where state is maintained on the server in application or session scope. The client thus knows about itself, and types of data it is requesting. It will request only the data it needs from the server, and no extra markup. This often leads to a cleaner services layer and less-complicated server requests, even in some cases a reduced overall load on the server.

It is also important to understand the sub-architectures within the overall architecture of the application. In the big picture, you have the client communicating with the server through a services layer. Whether you are using AMF remoting, XML over HTTP, JSON, or SOAP does not necessarily matter. There are pros and cons to each, which I may discuss at length in the future, but for now I’m focusing on the architecture itself.

Each component of the larger architecture has an architecture of its own. You may hear people discussing the use of MVC in their applications, but the interpretation of MVC depends on who is doing the talking.

Model-View-Controller (MVC) is a software architectural pattern where an application is broken into separate layers for the data model, the user interface (view), and the business logic. The logic, model, and views are decoupled, and communicate through an intermediary controller. This pattern enables both abstraction of logic, and reuse of code/components throughout the application. You can read more about MVC here.

In traditional web development, there was basically a singular MVC. Where the page requests were handled by a controller, which delegates how a page is processed and how the how the data is inserted into the view (or how data is pushed into the model).

In the RIA world, you really have two layers of MVC. There is an MVC inside of the client application itself, and an MVC in the backend services as well. Not every application uses a formal MVC or a full blown framework for handling the client and services, but each side typically has at least a rudimentary MVC-type of functionality.

The MVC on the client manages the interaction between you and the user interface. You invoke commands, update views, load data, etc… The client MVC maintains the state of the application, handles all requests to the server for data, and controls how the data is presented in the view.

The MVC on the server handles requests from the client. The services-layer MVC processes the requests from the client application, and delegates actions on the server. This could be saving data in a database, updating the file system, some kind of analytical processing, or returning chunks of data to the server. The big differentiation here is that there is no user interface. Instead of a user interface, the view would be the format of the data the is being returned to the client application. In this case the view would determine the result format (JSON, XML, etc…). Another benefit of a differentiated service layer is that you can already have the infrastructure built to create a public API on top of you services logic, if you have the need (or desire) to maintain one.

There is no definitive choice of technology for RIA. You can do lots of cool things with lots of different technologies. Back ends can be written in Java, ColdFusion, PHP, Rails, .NET, etc… On the client side, there are established MVC frameworks for Flex/Actionscript and AJAX, some emerging ones for Silverlight, and adapted Java frameworks for JavaFX. The determination of both the back-end and the front-end should be determined by the needs and capabilities of your application, and also your existing infrastructure.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: