The RIA pattern

Rich user interfaces are appreciated by users; however, their design and implementation are much more challenging. Developers have to cope with frequent user interaction and more complex presentation logic and state. Rich Internet Applications (RIAs) come in different architectural flavors, depending on the technology and product, yet represent enabling the web and creating better, more usable, more interactive software, an idea that spans the browser, the desktop and mobile devices. As such RIA naturally represents another Web 2.0 Design Pattern.

How so? When you develop an RIA, it can consume services using any runtime(s) without changing code, providing developers the capability to change their underlying runtime or simultaneously consume services written in different runtimes without having to make changes to the application. Applications and their UIs can be built to work on any platform and browser, using the skills developers presently have. RIA applications can also help enterprises develop applications that seamlessly integrate with, and extend the value of their SOAs.

What, then, constitutes the RIA pattern? It supercedes the familiar Model-View-Controller pattern by adding a presentation model to the picture. The presentation model is the cornerstone for a clean, extensible and testable presentation layer. which overcomes most of the inherent disadvantages of MVC pattern, such as overly complex view code or poor testability. This provides a Model-PresentationView-View-Controller architecture providing a separation of concerns between state and data access/changes.

The typical structure of UI libraries are as trees of components objects which represent the UI and event notifications which reacts to user activity, providing a simple layering of presentation logic over business logic. However, this does not support modular UI building.

Complex UIs require hierarchical component structures, which contains application components (ACs). There are application-related, coarse-grained UI elements built from base components from the UI library. UI developer utilise ACs rather than the base UI components, ias they map more usefully to task assignments. These UIs allow for redundant access to system parts - different ACs can display shared state - and for synchronisation of ACs. The common state is represented by the model, while ACs trigger and observe model changes and update themselves accordingly.

It follows to ask where MVC fails in this. In MVC, the Model represents business state - presentation state is not represented. As such, in MVC, Models and ACs become conflated. For example, an Inventory AC must reference a Product Catalogue AC to access artefacts such as categories. As a result, the ACs are not decoupled in MVC - the Inventory AC cannot be developed, tested, or used with out the Product Catalogue AC.

In the RIA pattern, we want to fully apply MVC to every single AC. This leads to having a separate layer representing this concept - the presentation model. Yet, how are models structured? What states are stored in a model? What are the quality attributes of the presentation model, how do we structure ACs therein, and what framework support is useful and necessary?

With respect to structure, ACs form a tree - the root corresponding to a desktop window. All relevant AC is maintained in a single model, yet models can share referenced models. As such, the presentation model instances form a directed acyclic graph, which enables unique mapping from AC nodes to model graph nodes.

State management in the presentation model only reflects mutable UI states; the state model is abstracted, so that state representation boils down to primitive values for simple UI states, and referenced models for complex states.

Quality attributes of the presentation model include a fully observable model state, through event notification - ACs observe the mapped model and updating themselves accordingly. As such, when a model is initialy bound to an AC, it must synchronise its entire state with the AC; the model triggers a set of events to sync the AC. The AC obtains the mapped model at construction time, each implementing three parts: a) Code to build its UI subtree from base components, b) a Controller to propagate base component changes to the presentation model, c) a Controller to propagate model changes to the base component. This provides the bi-directional update between ACs and their models.

Where do frameworks come in? They are useful for providing templates for model structures and ACs. With model structures, this eases as well as standardises the implementation of models - abstracting super classes and interfaces for models, providing models for lists, undo/redo, etc. With templates for ACs we have abstract classes with standard capabilities, such as i18n, factories for base components and controllers.

What does this mean for developers? With the RIA pattern, UI frameworks perform additional work designing and implementing the presentation layer, along with any additional controllers, yet they free ACs to be implemented, tested and used independently. The UI code can be uniform, easing maintenance and ramp up time. Common capabilities are provided virtually for free. Dynamic attributes such as locale can be handled in straightforward manner. It is far easier to change UI libraries, given component independence. All this enables a far cleaner business layer to be provided, and far more can be tested and validated without either the UI or the data store in place.

In following posts I will look at what else is needed, how the RIA pattern handles access to business logic, and payload delivery considerations.