Cairngorm. In a brief!

Here's a link straight from the horse's mouth as they say!

The Cairngorm - micro-architecture as a composition of design patterns, addresses three key areas that Adobe Consulting has long recommended as best-practices for their 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

There are four key benefits that Cairngorm provides:

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

Important Components

Following are the important components of Cairngorm:

A) Model - holds the data and the state.

Generally we create a ModelLocator as a composition class consisting of public static getInstance method returning a static singleton reference to itself. all the model objects are stored and refered to from this ModelLocator handle.

B) View - render data and watch the data changes with bindings. Views talk to controller with events.

C) Control - Control layer is implemented as following sub parts

a) Commands - implement execute method that crunches business logic and make use of the model. Create Responder by passing Remote Service Result Handlers and pass the responder to appropriate delegate in constructors. Then invoke asynchronous remote service operations on delegates.(implements com.adobe.cairngorm.control.ICommand).

Register the commands to Cairngorm framework in Front Controller by using addCommand(eventType, commandClass) method.

b) Delegates - Are like proxies for business service APIs. E.g. UserDelegate provides routing to Login, Logout, Registration. OrderDelegate provides Create, Update or Delete order.

To implement a delegate's service method, make use of ServiceLocator. Invoke the appropriate service and attach the responder to the async token of the service operation called.

c) Events - Make use of business events to trigger commands. Typically create one event for each command. Extend com.adobe.cairngorm.events.Event class.

d) Front Controller - Registry of Event to Command mapping. Intercepts dispatched business events and routes them to appropriate commands extends com.adobe.cairngorm.control.FrontController

e) Service Locator - Base your service locator mxml component on Cairngorm ServiceLocator (extend the com.adobe.cairngorm.business.ServiceLocator). Add service tags with id. In your delegate obtain reference as follows

var service:HTTPService=__locator.getHTTPService("UserService");
var token: AsyncToken = service.operation();
token.addResponder(responder);

General Benefits

- maintenance is easier
- debugging is easier
- feature additions and/or changes are easier
- automated testing of business logic and data access is easier
- using mock data-services is easier

SQLite Quick Reference!

:) Here's a quick 10 minute refresher overview on SQLite.

Making a RESTful Web Service call!

Another name for HTTP Service is REST style web service. To make a successful web service call we gotta take care of steps as below. Similar steps apply for HTTP Object instantiated via HTTP service tag.

1) Instantiate the HTTPService Object.
var httpService: HTTPService = new HTTPService();

2) Set the URL
httpService.url = "serviceURL"; //Mention the service URL

3) Set the method type [GET/POST/PUT/DELETE], default is GET
httpService.method = HTTPService.POST;

4) Set the resultFormat to XML [for true REST], default is Object

httpService.resultFormat = "xml"; //Values possible are object, xml, e4x, text, array, flashvars

5) Add result and fault event listeners

httpService.addEventListener("result", httpResultHandler);
httpService.addEventListener("fault", httpFaultHandler);

6) Construct the parameters to be passed if any, default is null. For example if
your service expects two parameters "userID" & "userName", the values of which you wanna pass as userIDValue and userNameValue, construct an object:

var serviceParameters: Object = {};
serviceParameters["userID"] = userIDValue;
serviceParameters["userName"] = userNameValue;

7) Make the call
httpService.send(serviceParameters);

Bingo! Have Fun! :)

REST vs. SOAP

Among all the rest that are there - here's a good link which exemplifies the differences between the two philosophies and lists out the Pros n Cons.

The fundamental difference between REST Web services and document-style Web services is how the service consumer knows what to expect out of the service. Web services have contracts, defined in WSDL. Since Web services focus on the service, rather than on the resource, the consumer has clear visibility into the behavior of the various operations of the service, whereas in REST's resource-oriented perspective, we have visibility into the resources, but the behavior is implicit, since there is no contract that governs the behavior of each URI-identified resource

Points to take home:

1) SOAP is a protocol for distributed XML based computing. REST is for simple point to point communication using plain old XML.

2) SOAP Envelope( optional header + mandatory body) is often bulkier for following reasons:

• a) Attributes: Since is designed to be used in a distributed environment with multiple nodes processing a SOAP envelope, its gonna contain role and relay attributes.
  
• b) Encoding [Rules on how a data value should be encoded in an XML format]
  
• c) Extensions and Versions
  

3) REST on the other hand is simple & concise -and it makes use of GET PUT POST DELETE methods of HTTP protocols to support CRUD communication over the network. REST using Flex Find it all here. But the bottom line is another name for Flex HTTPService class is REST style web service. For REST-style services, you use a server resource such as a PHP page, JavaServer Page (JSP) or servlet, or ColdFusion page that receives a POST or GET (or a PUT or a DELETE) request from a Flex application using the HTTPService component. That server resource then accesses a database using whatever means are traditional to the particular server technology.

The results of data access can be formatted as XML instead of HTML, as might be typical with the server technology, and returned as the response to the Flex application. Flex, Adobe® Flash® Player, and Adobe AIR™ have excellent XML- handling capabilities that let you manipulate the data for display in the Flex application user interface. REST-style services provide an easy way to access a server resource without a more formalized API such as those provided by web services or remote object services. These services can be implemented using any number of server technologies that can get an HTTP request and return XML as the response

Comparing LCDS ES 2 & BlazeDS

I did take a while to go back and find out the in detail differences between Adobe LCDS and BlazeDS offering - while Sujith Reddy G had it noted down here - It is available officially on Adobe's website here

In plain words, both BlazeDS and Adobe LCDS ES2 offer server side Remoting services(HTTPService, WebService, RemoteObject class), and Servlet based Messaging (MessageBrokerServlet class). LCDS additionally offers sophisticated Data Management services & Messaging services.

LCDS Data Management features are Real Time Data Synchronization & Change Management across clients, SQL Server & Hibernate Adapters and Data Paging & Lazy Loading.

LCDS Messaging features additionally include Real Time Push & NIO based Messaging.

The high level feature differences can be found on Flex Data Access section of Tour De Flex.