The ARIAWare RIA Platform and Pattern-Based RIA Development

A high-level overview of the client-side framework in the ARIAWare RIA Platform (ARP)

The ARIAWare RIA Platform (ARP) is a framework by Bits And Pixels that has evolved over many years and reflects the sum of years of experience with Flash and RIA development dating back to the Flash 4 and Flash 5 days. The foundations of ARP date all the way back to our experience in creating the world's first (and largest) RIA, the K12 virtual school that I helped develop in 2000 in Reston, Virginia. After leaving K12, I took a few months off to create the very first version of ARP, in Flash 5 and released parts of it as the open-source FC-Lib library. This evolved, in time, to Flash MX and parts were again released as open source as part of the Moose library. (Can you tell that I'm a big fan of open source?) In order to bring the platform in line with best practices in software architecture, we researched many standard software patterns and implemented them in a ground-up, complete rewrite for AS2 following our work on the first release of the Opal project. The current platform is written in an entirely new language (AS2) and contains no direct code from the Flash 5 or Flash MX versions or from the platform used during Opal. We currently do not have plans to open source the platform but we are holding consulting and training sessions on pattern-based RIA development and will be happy to consider licensing ARP on a per-case basis.

In this article, I want to take you through ARP and the design patterns we have used in creating it. In doing so, I hope you will also get a better idea of what design patterns are and which ones are the most popular (and useful) for Rich Internet Application development.

Design Philosophy

The design philosophy behind ARP involves embracing a Componentware approach to software development or Component-based Development. As stated in the Software Architect Bootcamp (Malveau, R, Moubray, Thomas J.), the elements of Componentware include:

Componentware uses polymorphism, encapsulation, late binding; delegation instead of inheritance.

ARP makes use of widely-known and accepted Design Patterns whenever possible. Design patterns are "proven software design ideas which are reused by developers" that are "considered as simple as common sense by expert-level developers." (p.50-51; Software Architect Bootcamp).

Template

The structural classes within ARP are implemented using the popular Template pattern. This pattern, presented in the Gang of Four book (p.325), is especially useful for class libraries such as ARP for placing common functionality within the library.

Applications based on ARP import and extend the base ARP classes (eg. Controller, Command). ConcreteClasses based on the templates must implement any Abstract operations (also known as "primitive operations") and may implement any required hook operations. (The Concrete Classes use the hook operations to extend the behavior of the template.) The contract for Abstracts operations is enforced using interfaces in AS2 to give greater compile-time error checking support.

The View

ARP is implemented in a manner as to allow it to work seamlessly with Form-based development in Flash MX 2004 Professional and future technologies such as Flex. It is also structured so that it can work with lightweight replacements to the Form architecture. This flexibility widens the applicability of ARP beyond standard RIAs to web sites and applications that require a smaller footprint without sacrificing application structure and maintainability.

We have developed in-house reference applications that use both the Flash MX 2004 Professional Forms and a lightweight alternative we call ARP Forms. ARP Forms are being used for the first time in a commercial configurator application for one of our clients. Currently, there are astronomic performance gains to using ARP Forms over Flash MX 2004 Professional Forms. Since ARP Forms implement the Flash Forms interface, once the performance issues with Flash Forms have been ironed out we can replace ARP Forms with Flash Forms (and vice-versa) in plug-and-play fashion. The same goes for using Flex as the presentation layer in future applications.

The Controller

The Ariaware Application Controller works in a fashion that is similar to the Controller described in the Command Procedure pattern document at openloop.com wherein it is stated "In essence, Controller is like a server waiting for request to map to Command objects". This is also in line with designs of the Controller pattern as stated in popular books such as Core J2EE Design Patterns (p.64). As stated there, "Control code may also be encapsulated in command objects that work in coordination with the controller" (p. 65) and "Encapsulate code related to lookup services and caching in Business Delegate" (p.302). This is what we have implemented in ARP.

ARP, thus, allows the use of a Controller to map View events (which we call System Events) to Commands. The Controller listens for System Events and maps these to Commands. We have taken this implementation one step further using a naming convention that automates the mapping process while minimizing the chances of coding error and halving the amount of code that would otherwise be necessary. This convention brings further structure to the application and improves our maintainability.

Commands

Commands are implemented in a standard manner, as discussed in Javaspaces Principles, Patterns and Practice, p. 166 (Freeman, Harper, Arnold; Sun/Addison-Wesley). In addition, we have taken the advice of Core J2EE Design Patterns p. 302 in delegating "code related to lookup services and caching in Business Delegate".

The Controller acts as the Invoker and the Business Delegate and the View are both Receivers.

One of the shortcomings that we noticed during the development of the Opal project was how the framework being used could not handle multiple views for a single command. This lead to the duplication of commands to service different views and quite a few headaches. Although we brought up the issue during development, time constraints meant that we couldn't implement a solution for that platform at the time. We're happy to have created a system now that does not necessitate the duplication of commands to service multiple views.

In ARP, the Controller creates Command instances for each service call and the Command instances are each passed a reference to the view that they pertain to.

Although we had come to the conclusion that View Helpers would be necessary for Opal, our new ARP framework does not require their use. In ARP, public methods within thew view serve this purpose. We now view (no pun intended) View Helpers as an artificial and unnecessary addition to a Flash-based RIA/platform in AS2.

Business Delegate

The Business Delegate hides the client from the complexity of remote communication with business service components. It hides the implementation details of the business service, such as lookup and access mechanisms. It reduces coupling between client and system's business services and possibly shields client from volatility in implementation of business service API. (Core J2EE Design Patterns p.302)

Business Delegates are implemented in a standard manner as stated by Core J2EE Design Patterns (p.302) to "Encapsulate code related to lookup services and caching".

Specifically, the model given on p.302 describes our implementation of the Business Delegate, with the Command acting as Client.

Service Locator

The Service Locator is an abstraction that allows us to decouple the service location function of our applications from the service consumption function. The Service Location in ARP is a slight variation of the implementation of the Service Locator as outlined in Core J2EE Design Patterns (p.316). The Service Locator, thus, is a singleton that returns an instance of a service when asked for it by name. For the most part, in our development, a Service means an OpenAMF (Flash Remoting) Service but could easily mean a web service or a local implementation that interacts with local or remote shared objects, etc. To add yet another layer of abstraction and increase our flexibility, we have implemented a hot-swappable GatewayConnection singleton that is utilized by the Service Locator for connecting to different types of services: Gateway connections currently exist for Flash Remoting, Local Shared Objects, Remote Shared Objects, Video and Audio (using Flash Communication Server) and local files (xml, flat file).

Value Objects

We use Value Objects (sometimes referred to in the latest Flash documentation as Transfer Objects) to model problem domain objects and structure the exchange of data among the various tiers. You can find a good explanation and implementation of Value Objects over at the Java Practices web site.

Singletons

ARP makes use of the Singleton pattern in implementing quite a few of its components. These implementations are standard implementations of the pattern as widely published (e.g., Applied Java Patterns. Sun Microsystems Press, p.37).

Components

A Componentware approach to software development would not be complete without components and we use quite a few in our daily development. In addition to the standard Macromedia Flash MX and Flash MX 2004 components and the ones in the DRKs (most of which we have heavily extended using the Decorator pattern and/or optimized for performance) we utilize third party components as well as our own custom components. Our current range of custom components includes a robust Menu component that uses the Composite pattern and introspection to automatically draw itself either as a menu bar, toolbar, image button or a simple text button, a movie loader component based on the FC-Lib Movie Loader class and its big brother, the Tornado Movie Loader that allows us to implement intelligent preloading in applications, a custom Data Grid component that implements the Macromedia DRK Data Grid interface while offering a performance improvement by a factor of ten as well as other helpers and components.

We have plans to package and license some of these components in the very near future, to coincide with the official launch of our new ARIAWare brand, so keep your ears peeled!

In Conclusion

We have put a lot of time and energy into creating ARP, the Ariaware RIA Platform, and it is already proving to be a great enhancement to our productivity. ARP allows us to rapidly develop Rich Internet Applications that are easily maintainable and scalable. Our experience with Flash since the early Flash 4 days and our work in RIAs dating back to the Flash 5 days means that we know a thing or two about what works and what doesn't for n-tier rich-client web application development using Flash. The delicate balance lies in adapting current best practices to Flash in a performant manner that suits the limits of Flash while guaranteeing maintainability and scalability of the application. ARP is one tool in our toolbox that lets us do that.

In this article, I have only discussed the client-side architecture of ARP and that is really only half the picture. ARP also comprises a J2EE-based server-side framework architected by Isiltan Kef, our Lead Java Developer, and I have a nasty suspicion that he will be publishing some details about it in the near future.

I hope you enjoyed reading about the various design patterns and how we've used them in ARP. We would encourage anyone interested in developing RIAs to learn and use design patterns in their own work. There is a wealth of information, both online and in books, regarding design patterns and their implementations. Although certain patterns solve problems that only really relate to certain platforms (e.g. traditional web application development in a stateless environment), many others can be implemented directly in ActionScript, many times through adapting standard, published, reference implementations.

Ariaware RIA Platform and ARP are trademarks of Bits And Pixels, Ltd.

Comments