Flex Architecture Fundamentals Part 1 : Rich Internet Application Server Architecture Basics

This post belongs to a four part series :
Part 1 Rich Internet Application Server Architecture Basics
Part 2 Main Means Of Communication Between Flex And The Application Server
Part 3 Designing the Flex application as a Model View Controller
Part 4 Using Architecture frameworks

As a follow up to Andrew Trice's article on Rich Internet Applications architecture, combined with the fact that since I discovered lovelycharts I can't help drawing diagrams for any reason, I have decided to share my own story about Flex architecture.

Please keep in mind that this does not pretend to be an in-depth coverage of Flex or RIAs architecture. This, for the most part, is taken from the Flex training I run at Regart.net, so it's sometimes very pragmatic, at the expense of accuracy.

Rich Internet Application Server Architecture Basics

For the sake of simplicity, we'll consider that a Rich Internet Application (RIA) is a web application which client is a rich client (sometimes referred to as a web 2.0 applications), such as Ajax, Flex, Silverlight or JavaFX.

Most web applications are structured as three-tierd applications, which, to some extend, can be compared to the Model View Controller (MVC) architectural pattern. The MVC pattern distinguishes three parts in the application : the Model, where the data is gathered, the View, which represents the data from the Model graphically and receives user inputs, and the Controller, which processes the user inputs coming from the View to update the Model.

In the context of a web application, the Model is the data source, the Controller is an application server, while the View is the client.

In the case of a Flex RIA, the Controller can take the form of a Service (or business object) on the application server that reads and updates a Database (the Model) when it receives requests from the Flex application which, itself, represents the DataBase records to the user.

The application server's architecture can vary from a simple page or script, to a complex architecture. A very common pattern implemented in this case is the Data Access Object pattern, where the Service delegates to other objects (the DAOs) the responsability to perform Create, Read, Update and Delete (CRUD) operations on the DataBase. These DAOs will map the results into Data Transfer Objects (DTOs), also called Value Objects (VOs) which basicaly represent a DataBase table record as an object. It is those VOs that the service will receive, manipulate, and send back to its clients.

With J2EE application servers, the business layer in which resides the Service may be handled by frameworks such as Spring, which can communicate with DAOs that belong to a persistence layer. This persistence layer that can be handled with an Object Relational Mapping library such as Hibernate.

With PHP application servers, some frameworks like Cake PHP or Zend can handle similar jobs.

In the .NET world, as far as I know, such features are supported by ADO.NET or, again, Hibernate.

But the Flex application does not have to care about the details of implementations of the controller. The way it deals with requests and responds to it is definetly in Flex's not-my-problem realm, exactly like a View does not have to care about what its controller actually does. It just has to know how to communicate with it.

So basically, the Flex client will have to communicate with a Service that may expect and return, among other things, Value Objects. As a Flex developer, you have to know the Service location and API which can therefore consist of both methods and, sometimes, Value Objects.

Of course, you'll have to choose a way to communicate with this Service. This is precisely what we'll cover in Part 2 of this series.

Additionnally, I'd like to share Duane Nickul's Slide on Web 2.0 design patterns, models, and analysis, and some other online references.


Adrew Trice's article Understanding The Architecture of a Rich Internet Application

Web 2.0 design patterns, models, and analysis

Model View Controller on Cunningham & Cunningham, Inc.'s wiki

Sun's Java BluePrints : Model-View-Controller

Integrating Flex with Java

Martin Fowler's Patterns of Enterprise Application Architecture

MVC.jpg17.61 KB
MVC_ClientServer1.jpg19.01 KB
MVC_ClientServer2.jpg19.96 KB
DAO (Flowchart).jpg44.63 KB

Anonymous on February 13th 2008

*Waiting for part 2* :)

Ced (not verified) on September 13th 2010

Thanks for this tutorial. Understanding this design pattern is an importante step toward communication btw the server and Flex RIA. But I wish there were more resources discussing the next step. That is:

- When and how much data should an application load.

- How fare your RIA should be statefull.

- What strategies to update your RIA model.

Some will argue that it depends on your application but there is definitivly patterns here.

Any books, or web resources to recommand ?