This series presents an open-source architectural framework to Flex developers called Cairngorm. In this series I explain the thought leadership behind Cairngorm, the design challenges that Adobe feels Cairngorm addresses best, and the projects for which Cairngorm is an appropriate skeleton for development.

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

Finally, I 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. However, Adobe Consulting has helped numerous customers and partners succeed in delivering large-scale Flex RIAs by building upon their preexisting Flex application development knowledge using the information contained in this series.

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, the first part offers a context and background for understanding the Cairngorm architecture. I discuss frameworks and clarify the difference between an application framework and an architectural framework. I then explore design patterns and introduce the microarchitecture concept. Finally, I give a brief background on the emergence of Cairngorm: its history and where it is headed - its roadmap.

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.

Clarifying the Definition of Frameworks
In software development, the term framework is one of the most overloaded and overused terms within and between development teams. When developers write large pieces of code that they consider significant enough to consider leveraging 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 the like.

Before I delve into the discussion of the Cairngorm framework, it's important that I explain an important distinction that the Adobe Consulting team shares with customers and partners about frameworks - specifically the distinction between application frameworks and architectural frameworks.

Application Frameworks
Flex is a tremendous example of an application framework. In fact, the forthcoming release of Flex 2.0 actually distinguishes the application framework piece - often called the "app model" within Adobe - in its architecture. The Flex Framework 2.0 provides a rich collection of class libraries that provide highly granular functionality that developers can use to create custom code. For instance, the Flex 2.0 Collections API provides application developers with all the base-level functionality needed to create managed data collections. Application developers then compose these collections together into higher-level objects that are relevant to their particular application. Furthermore, application frameworks such as Flex typically expose application-level services such as history management, layout management, cursor management, exception handling, internationalization, logging, and so forth.

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

Another excellent example of an application framework is the FAST framework that Adobe Consulting has used with customers and partners with great success. The FAST framework, as John Bennett explains in his article, Faster Development with the Flex Application Starter Toolkit (FAST), provides application services for logging and tracing, and value-add class libraries that extend the Flex Framework's own implementation of RPC data services in Flex 1.x.

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 except an infrastructure around which an application can hang - to 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.

Without going into detail about software design patterns, let me just 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 regular consistency in application development. Almost as consistent as their appearance is the repetition of solutions for these problems. Wherever such recurrences occur, you can identify the solution as a "pattern," indicated by facing 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 of a catalog of solutions to their engineering problems can be a powerful one. Often developers recognize a subset of problems they have encountered and then seek to understand other design patterns and where they might apply them. However, 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.

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 the way developers apply them to an application indicates the intention of the implementation. For instance, whenever you see a Singleton 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, you recognize that there are a number of different objects that a manufacturing class can construct.

Rising through the technical architecture - from the ground-zero of detailed implementation towards the helicopter view of high-level system design - you can begin to appreciate the design in other, recurring ways. Like the Mandelbrot, 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
Although a design pattern might have offered a specific solution to a specific problem (in this case, using the Singleton pattern for the problem of ensuring that only one instance of a class ever exists), when a collection of patterns regularly collaborate with one other, their assembly is for the greater good of a greater aim: "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 these higher order but nonetheless highly generic systems, you communicate these as "microarchitectures."

Let's take this high-level discussion of application frameworks, architectural frameworks, design patterns, and microarchitectures and put it into context. When Adobe Consulting 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 framework that offers a little prescription 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 ever so 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

A Short History of Cairngorm
iteration::two, a software consultancy that Alistair McLeod and I cofounded, 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 these 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 a chapter called "ActionScript 2.0 Design Patterns for RIA Development" in Macromedia Flash MX 2004 ActionScript 2.0 Dictionary (Macromedia Press, 2003).

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. However, the Flex programming model offered us ever more elegant ways to implement these patterns. Furthermore, some patterns that we considered hugely valuable to Flash RIA developers (such as the ViewHelper pattern) became less relevant in the Flex RIA world, allowing us instead to advocate new Flex-specific patterns of our own, such as the ModelLocator pattern.

At MAX 2004 we announced our decision to release the Cairngorm framework as an open-source project for Flex; a decision that has led very much to its widespread adoption within the community.