Developing Flex RIAs with Cairngorm microarchitecture - Part 1: Introducing Cairngorm

Additional Requirements

Cairngorm version 2.2

• Download Cairngorm version 2.2

Cairngorm Store

Throughout the series you will find references to code taken from an e-commerce application named Cairngorm Store. You may use this sample application to gain a better understanding of Cairngorm, but please consider it only as a guide. Adobe is not responsible for maintaining the Cairngorm Store application.

• Download Cairngorm Store (J2EE Container version)
• Download Cairngorm Store (non J2EE Container version)

This six-part series presents an open-source architectural framework for Flex developers called Cairngorm. In this series, we explain the thought leadership behind Cairngorm, the design challenges that Cairngorm addresses best, and the types of projects for which Cairngorm is an appropriate skeleton for development.

Using the Cairngorm Store sample application, this series explains how the Adobe Consulting team thinks about scoping, estimating, and delivering a rich Internet application (RIA) when basing it on Cairngorm from the start. We also explain various Cairngorm concepts and take a deep dive into the implementation of the Cairngorm Store.

Finally, we demonstrate some of the principal benefits of delivering an RIA based on this established microarchitecture by adding a new feature to the existing Cairngorm Store application from the point of view of a Cairngorm developer. By this stage in the series, you see the benefits for yourself.

Cairngorm isn't the only way to build a rich Internet application, of course. Adobe Consulting, however, has used the information contained in this series to help numerous customers and partners successfully deliver large-scale Flex RIAs by building upon their preexisting Flex application development knowledge.

This comprehensive introduction covers the full spectrum of Cairngorm, from understanding the motivation and concepts of Cairngorm to architecting your own applications upon this established and supported microarchitecture.

Instead of delving into code from the outset, Part 1 provides the context and background for understanding the Cairngorm architecture. We discuss frameworks and clarify the difference between an application framework and an architectural framework. We then explore design patterns and introduce the microarchitecture concept. Finally, we give a brief background on the emergence of Cairngorm: its history and where it is headed—its roadmap.

In Parts 2–6, you will develop a retail commerce application using both Flex and Cairngorm on the client-side tier and a new or existing J2EE infrastructure on the server-side tier.

• Part 1: Introducing Cairngorm
• Part 2: Keeping state on the client
• Part 3: Architecting the view
• Part 4: Feature-driven development
• Part 5: Server-side integration
• Part 6: Rapid and consistent development with Cairngorm and Flex

In software development, framework is among the most overloaded and overused terms. When developers write large pieces of code that they consider significant enough to leverage on other projects, they tend to supplement the code with this term. Thus there are many types of frameworks: persistence frameworks, transaction frameworks, logging frameworks, aspect-oriented frameworks, animation frameworks, unit-testing frameworks, and so on.

Before we delve into the discussion of the Cairngorm framework, it's important to note an important distinction that the Adobe Consulting team shares with customers and partners—specifically the distinction between application frameworks and architectural frameworks.

Application Frameworks

Flex is an excellent example of an application framework. The Flex 3 Framework provides a rich collection of class libraries with highly granular functionality that developers can use to create custom code. For instance, the Flex 3 Collections API provides application developers with all the base-level functionality needed to create managed data collections. Application developers then assemble these collections into higher-level objects that are relevant to their particular application. Furthermore, application frameworks such as Flex typically expose application-level services, including history management, layout management, cursor management, exception handling, internationalization, logging, and other services.

When a framework features highly granular class libraries that provide a high degree of flexibility to application developers, or when a framework provides application-level services that are useful across multiple developer projects, we call it an "application framework."

Architectural Frameworks

Architectural frameworks are different beasts entirely. Typically, the job of an architectural framework is not to provide any additional services to application developers beyond an infrastructure around which an application can hang. Architectural frameworks provide the skeleton or internal structure of moving parts, around which the flesh and muscle particular to a business domain can be layered.

In other words, an architectural framework provides a generic starting point for the technical architecture of your application.

Applying design patterns

It is hard to talk about technical architecture without paying attention to an important movement in software engineering called design patterns.

While we won’t go into detail here about software design patterns, we will say that the expression "there is nothing new under the sun" is never more true than in the discipline of software engineering. Developers often find themselves addressing engineering problems that appear with regularity in application development. Almost as consistent as their appearance is the repetition of similar solutions for these problems. Wherever such problems occur, you can identify the solution as a "pattern," indicated by identifying the design challenge and finding the appropriate design solution.

The lure of design patterns

Now a warning: When software engineers first encounter design patterns, the realization that there exists a catalog of solutions to their engineering problems can be powerful. Often developers recognize a subset of problems they have encountered and then seek to understand other design patterns and where they might apply them. The old adage "when all you have is a hammer, everything looks like a nail" can apply here. You can often find "pattern overload" in an application, where developers abdicate responsibility for classes and collaborations and, instead shoehorn everything into a Factory, Flyweight, Observer, or Decorator design pattern.

Used appropriately, however, design patterns can be a powerful tool in a developer's toolbox. Design patterns not only offer common solutions to problems, but they can also indicate the intention of the implementation. For instance, whenever you see a Singleton design pattern in a code base, you understand that this is a class for which there should be only one instance. Likewise, whenever you come across a Factory pattern, you recognize that there are a number of different objects that a manufacturing class can construct.

Rising through the technical architecture—from the ground-level detailed implementation towards the helicopter view of high-level system design—you begin to appreciate the design in other, recurring ways. Like the Mandelbrot set, you begin to recognize higher order structure as your lower level structure collaborates. Thus design patterns begin to coalesce in repeatable ways, offering higher level solutions to higher level design problems.

Microarchitecture as a composition of design patterns

While a design pattern offers a specific solution to a specific problem (for example, using the Singleton pattern for the problem of ensuring that only one instance of a class ever exists), a collection of patterns that regularly collaborate with one other can be assembled for the greater good of a greater aim. For example, such collections of patterns can be used to provide answers to questions such as, "How do I intercept user gestures and ensure that a worker class assumes responsibility?" or "How do I centralize the business logic that might be used in more than one context on the client, even though it is actually implemented as a collection of service calls to a number of different types of services on a collection of servers?"

When you start to assemble collections of design patterns into higher order but nonetheless highly generic systems, you communicate them as "microarchitectures."

Let's take this high-level discussion of application frameworks, architectural frameworks, design patterns, and microarchitectures and put it into context. When the Adobe Consulting team speaks about the Cairngorm framework, we are speaking about an architectural framework—a starting point for technical architecture that is generic enough to apply in most cases to medium-to-complex Flex RIAs.

Furthermore, when we speak about the Cairngorm framework, we do not mean some monolithic architecture that limits your freedom as a developer to solve problems. Rather, when we advocate the Cairngorm framework, we mean the following:

• A lightweight, prescriptive framework for some of the challenges consistent with the Flex RIAs we have encountered
• Using a small number of relevant design patterns, where the moving whole is slightly greater than the sum of its static parts
• A microarchitecture for RIA development—a starting point for your technical architecture that solves the problems as they have been solved successfully before

If we can see further, it is because we are standing on the shoulders of giants.

When Alistair McLeod and Steven cofounded the software consultancy iteration::two, we recognized that many of the design challenges faced and successfully solved in the world of J2EE application development were still relevant issues in the world of RIA development. We came to this realization back in the days of RIA development with Flash, Flash Remoting, and J2EE—a period of RIA history that we'll look back upon with the same fondness and nostalgia as a C++ programmer has for 6809 assembly language.

Borrowing a subset of a collection of design patterns advocated by Sun Microsystems as the Core J2EE Pattern Catalog, we first presented our set of design patterns to the Flash community in our book, Reality J2EE: Architecting for Macromedia Flash MX (Pearson Education, 2003). To accompany the release of Flash MX 2004, we presented the patterns in Macromedia Flash MX 2004 ActionScript 2.0 Dictionary (Macromedia Press, 2003) in a chapter titled "ActionScript 2.0 Design Patterns for RIA Development".

As the RIA technology platform matured from the design-centric approach of Flash towards the declarative programming model of Flex, most of the motives for applying these patterns remained. The Flex programming model, however, offered us even more elegant ways to implement these patterns. Furthermore, some patterns that we considered exceptionally valuable to Flash RIA developers (such as the View Helper pattern) became less relevant in the Flex RIA world, leading us instead to advocate new Flex-specific patterns of our own, such as the Model Locator pattern.

Back at MAX 2004 we announced our decision to release the Cairngorm framework as an open-source project for Flex; that decision has since led to its successful and widespread adoption within the community.

The Cairngorm microarchitecture addresses three key areas that Adobe Consulting has long recommended as best-practices for our customers and partners:

• Handling user gestures on the client
• Encapsulating business logic and server interactions
• Managing state on the client and representing this state to the user interface

Cairngorm offers a microarchitecture (collection of design patterns) to help consistently solve these recurring design challenges.

As you read this series of articles, you’ll gain a deeper understanding of how design patterns are applied in the development of RIAs, including:

• How the Front Controller and Command patterns implement a "Service to Worker" microarchitecture for listening and responding to user requests.
• How the Business Delegate and Service Locator patterns interact so that you can reuse and encapsulate business logic and establish a clear contract between client and server-side development teams, independent of server-side technical implementations such as LiveCycle Data Services, web services, Enterprise JavaBeans, ColdFusion components, or even RESTful architectures using XML over HTTP.
• How the Value Object pattern from J2EE can collaborate with the Model Locator pattern to enable an elegant strategy for maintaining a stateful client with a rich and cinematic user experience.

The current state of Cairngorm

Cairngorm, currently at version 2.2, has constantly evolved alongside Flex. Today, Cairngorm has a broad user base that has successfully used the framework in their development efforts. The Cairngorm Committee has also grown; it is now comprised of a committed core of Adobe consultants and engineers, as well as numerous community members.

The core Cairngorm concepts remain the same. Only the underlying implementation has changed to keep pace with additional thought leadership and best practices on how to leverage the features within the latest version of Flex, such as LiveCycle Data Services including Flex RPC Services. Be sure Cairngorm will track the latest release of Flex.

Note: In the final article of this series, we explore the criteria you can consider as you decide when to use Cairngorm—and when not to use it. We do not mean to suggest that Cairngorm is the only way to build rich Internet applications. Nor do we even suggest that the best practices we present are the only best practices. In fact, others may promote best practices that seem to contradict what Cairngorm suggests.

We do, however, recommend that you first try to understand the problems that Cairngorm is intended to solve before attempting to solve them with Cairngorm. If you are just learning Flex as you build one of your first rich Internet applications, we strongly suggest that you become comfortable with the many new tools and techniques that the technology and platform offer you before complicating your learning curve with Cairngorm.

This is not to say that Cairngorm is complex. On the contrary, it is important that you be confident and comfortable building simple RIAs that do not require the benefits of a technical architecture such as Cairngorm before taking advantage of the benefits that Cairngorm offers.

Parts 2 through 6 will ensure that seasoned and novice Flex developers alike understand the RIA challenges that created the problems that Cairngorm solves. This series is intended to explain as clearly as possible—using detailed code-level examples—the elegant way in which Cairngorm can help you solve them.

Where to Go from Here

As Part 1 of a six-part series, this article introduced the Cairngorm framework by clarifying the ambiguity around the definition and usage of frameworks, explaining why you might use a framework, and providing an overview of the origins and the future of the Cairngorm framework.

With Flex, you can build your own, more complex, application-specific architectures using the suggested implementation of a technical architecture that the Cairngorm architectural framework provides. By basing your application on the Cairngorm architecture there are some generic and fundamental design challenges that you won't have to solve by yourself, such as how to handle user gestures in an elegant fashion, how to handle server interaction and business logic in an elegant and scalable fashion, and how best to manage state on a rich and immersive client application.

As we noted earlier, iteration::two borrowed software design patterns that were useful to us as J2EE developers, and re-applied them in RIA development. Having an aerial view of the technical architecture often helps developers identify recurring collaborations of design patterns. The realization that such collaborations, known as microarchitectures, exist is the foundation of the Cairngorm framework.

When consulting, we often say that the difference between theory and practice is that, in theory, there's no difference between theory and practice. In Part 2, we move past the discussion of context and background of design patterns and microarchitecture, and present the four key benefits that Cairngorm provides:

• Maintaining state on the client
• Architecting the user experience
• Implementing feature-driven development
• Invoking server-side services

In Part 2, you'll get a hands-on feel for how to leverage the Cairngorm framework in application development, the problems that Cairngorm solves, and the ease with which you can consistently deliver highly scalable, maintainable, and robust rich Internet applications with Flex.

Developing Flex RIAs with Cairngorm microarchitecture – Part 2: Keeping State on the Client