Home  >  Development  >  features

Anatomy of an Enterprise Flex RIA Part 13: Building the Flex Service Layer

| | Comments (0)
AddThis Social Bookmark Button
 
riaseries_part13.jpg

Now let’s look at the Flex service layer, which comprises the classes where we define the data services we’ll access, the definition of the service methods we’ll access, and the logic for calling those services and what to do when the services return.

Getting Organized with Cairngorm

The first, and certainly the most popular, framework for Flex applications is called Cairngorm. Cairngorm was created by Steven Webster and Alistair McLeod, who ran iteration::two, a consulting company which later became the EMIA RIA practice of Adobe Consulting. Cairngorm is now an open source product distributed by Adobe Labs (http://labs.adobe.com).

Let’s get this bit out of the way too, because a lot of people hear the name and reply with a quizzical look: Cairngorm is a funny name, yes. It’s named after a mountain in the Nevis mountain range in Scotland. iteration::two was using Scotland mountain ranges as code names for internal libraries, and Cairngorm stuck after it went public.

Cairngorm is a micro-architecture, which means that it’s more like a set of patterns to aid in architecting an application.

It also has nothing much to say about how you architect the view of your application either; it’s mostly about how you glue the interactions between the different pieces of your application with each other and with the services that support the application.

Cairngorm helps developers architect the application according to the Model-View-Controller (MVC) principle, which is common to many visual applications. MVC distributes responsibility of components over three types of classes: the model, which holds the data; the view, which displays that data; and the controller, which brokers the interactions on the view with the data in the model, keeping the view and model uncoupled.

Cairngorm gives developers a model in the Model Locator, and a controller, which is a collection of commands (we’ll discuss these shortly). The view is pure Flex and makes good use of Flex’s powerful binding framework.

Cairngorm employs a set of best-practice design patterns to help you architect your Flex application in the most flexible (no pun intended) way possible. Table 10 lists some of these patterns.

Table 10: Best-practice design patterns employed by Cairngorm
PatternDescription
Front ControllerThe Front Controller pattern is a Controller pattern for maintaining some level of centralized control over interaction between the view layer and more business-logic-oriented parts of the application.
Cairngorm’s controllers are basically mappings of events to commands (discussed shortly), and they delegate responsibility to the commands to implement the business logic.
Event Dispatcher/Event ListenerMany times in Flex and Flash and, in fact, in most visual non-web development, you’ll be struck by how often the interaction between the different parts is asynchronous, or how much interaction happens via callbacks.
Cairngorm has an EventDispatcher which is how the view informs the Front Controller of a user gesture.
CommandThe Command pattern defines objects that are responsible for executing a discrete action, usually in response to a user “gesture,” which is a user’s interaction with the application, such as a click on a button or a selection from a menu.
Cairngorm commands come in a few flavors. Basic commands simply execute and are done. Responders execute and listen (asynchronously) for a response from another part of the application, usually a service response.
Business DelegateThe Business Delegate pattern is a way to keep the application supple and uncoupled to the “backend” service layer. If each piece of the application that had to interact with the underlying service knew which method names to call and which arguments the service needed, that would make refactoring that service hard, because any calls to the service would have to be tracked down and changed.
The Business Delegate pattern stands between the various parts of the application calling services and the services themselves. Often, the names of the delegate’s methods are the same as the backend methods. In this way, the delegate acts as a wrapper to the service layer and “delegates” the actual implementation to the service layer.
When delegates are used, if the service needs to change its API in any way, it’s clear where the client part of the application needs to change—in the delegate. The delegate’s API need not change, unless there is good reason, and if it does need to change, all of the delegate’s callers are written in the same language, which makes it trivial for an IDE to track down any calls to the delegate for easy refactoring.
Model LocatorThe Cairngorm team invented the Model Locator pattern. This pattern defines a singleton model, which allows views or commands to get a reference to a specific model from the model itself instead of the more cumbersome method of passing a reference anywhere the model is needed.
Service LocatorThe Service Locator pattern, just like the other *Locator patterns, defines a singleton which provides easy access to service definitions.
Services in this case refer to the various service definitions in the LCDS configuration that point to the Java objects, data services, HTTP services, web services, message queues, and so forth that are possible data sources for the Flex part of the application.

The best place to learn more about the interactions within Cairngorm is at http://www.cairngormdocs.org.

A typical interaction with Cairngorm goes as follows:

  • User gesture
  • CairngormEventDispatcher
  • Command
  • Delegate
  • Service
  • Command (as Responder)
  • Model
  • View changes (through binding)

Generating Cairngorm Classes

As I mentioned in the discussion about tools, Cairngorm projects go a lot smoother with some code generation. Cairngen helps out by providing utility Ant tasks and template files to fit your project’s needs. Some of the tasks include those for generating the common Cairngorm directories in your Flex package structure, and those for generating a ModelLocator, ServiceLocator, and FrontController. These tasks are especially helpful at the beginning of a project, but not much after that. I find Cairngen most useful in generating what it terms a “sequence”: a CairngormEvent, a command, and possibly a delegate with similar names and a string constant on the event as a unique identifier to put into the FrontController to register the event to the command.

If you download Cairngen yourself, you’ll get a build.xml and project.properties file, and a config and template directory. I’ve moved the contents of that build.xml to our ui project build.xml: feel free to look that over, but we won’t need to change anything there.

I also renamed the project.properties file to cairngen.properties, but left the config and template directories as is.

Notice in Figure 17 that the templates directory contains just the templates for the different types of generation of Cairngorm 2.2 classes. You can modify those templates to fit the needs of your project (e.g., match the brace style your team uses, add comments, etc.).

anatomy13_fig17.jpg
Figure 17. Cairngen Files

The only configuration you need to do is inside the cairngen.properties (formerly project.properties) configuration file:

############################### FLEX BUILDER PROPERTIES 
root.dir       =./src/main/flex

################################# PROJECT PROPERTIES 
project.name   =Bookie
com.dir        =lcds
domain.dir     =examples
project.dir    =bookie
namespace      =${com.dir}.${domain.dir}.${project.dir}
project-uri    =${root.dir}/${com.dir}/${domain.dir}/${project.dir}

################################## SOURCE MANAGEMENT 
overwrite.existing.files =false

################################ CAIRNGORM PROPERTIES 
cairngorm.version  =2.2

################################# CREATING SEQUENCES 
sequence.name      =BooksChosen

################################### CREATING VOs 
vo.name            =HelloWorld

Here we tell Cairngen where the source goes, the name of the project, and information about the package structure. Here’s a list of the Cairngen tasks:

  • clean (remove all Cairngorm-standard directories and as well as the model, service locator, controller, sequence, and VO)

  • create (create Cairngorm-standard directories; generate the model, controller, service locator, sequence, and VO)

  • create-cairngorm-directories (Cairngorm-standard directories)

  • create-front-controller

  • create-model-locator

  • create-sequence-exclude-delegate

  • create-sequence-include-delegate

  • create-service-locator

  • create-value-object

  • delete-cairngorm-directories

The tasks I end up using most are create-sequence-exclude-delegate and create-sequence-include-delegate. These tasks take the property called sequence.name from the properties file and generate an event called Event and a command called Command. The include-delegate version makes the command an IResponder (with a result and a fault method) and creates a Delegate class. This is for use with commands that are meant to call a service method. I usually move the generated delegate’s methods to a single consolidated delegate class.

Each time you want to generate a new sequence, you edit the properties file to add the name of the sequence you need, and then run the applicable Ant task.

Next time we'll continue looking at the components of Cairngorm as we finish looking at the Flex service layer. You can always find the entire series here.

Comments

Leave a comment


Type the characters you see in the picture above.

Tag Cloud

Related Books

Development Series

Get an overview of the tools and technologies that work together to allow developers to build Rich Internet Applications (RIAs) quickly and easily.

Anatomy of an Enterprise Flex RIA

Recent Comments

Archives


 
 


Or, visit our complete archive.  

About This Site

Welcome to the premiere community site for all things RIA sponsored by O'Reilly Media and Adobe Systems Incorporated.

About Us
Meet the Experts
Meet Our Contributors
Send Us Feedback