Accessibility

Table of Contents

Developing Flex RIAs with Cairngorm microarchitecture – Part 5: Server-side integration

Integrating with Flex RPC services

When developing a rich Internet application, one challenge is deciding which functionality the application can and should execute on the client, and which functionality should reside on a server. In evaluating these tradeoffs, you might take into account issues such as performance, scalability, and security. In other cases the decision may simply be dictated by the desire to provide a rich user experience based on an existing investment in server-side infrastructure.

One luxury of rich Internet application development is the seamless means by which server integration now occurs. With a web application, a request to the server for data typically results in a page refresh for the user. With an RIA, however, the user is oblivious to the distinction between client-side and server-side processing. Requests for data do not interrupt the flow of control; instead, data requests are made asynchronously and the application is notified when these results become available.

There are a number of mechanisms available for integrating a Flex RIA with server-side data. Flex data access components use remote procedure calls (RPCs) to interact with server environments. There are three Flex data access components:

  • HTTPService: Passes textual data over HTTP. This is often used to fetch RSS feeds, read XML generated by a server, or simply pass text-based data from server to client.
  • WebService: Allows a Flex application to invoke server-side web services using SOAP and handle the results of web service calls. These web services may reside on the server that has served the rich Internet application or may call third-party web services through a proxy on the server.
  • RemoteObject: Allows a Flex application to directly invoke methods on Java classes residing on the application server that has served the RIA. Data is transferred in binary format (Adobe Action Message Format or AMF) over HTTP or HTTPS, with the server translating Java and ActionScript objects as they pass over the wire.

A discussion of client-server integration and a detailed exploration of these components are both beyond the scope of this article. The Flex documentation, however, provides extensive information on each component. In addition, Steven's book, Developing Rich Clients with Macromedia Flex, includes a discussion on why you might choose one method over another.

Flex provides three MXML tags—HTTPService, WebService, and RemoteObject—that do a significant amount of heavy lifting for application developers. Using these tags, you can easily specify a service location (URL, WSDL location, or Java class), invoke methods on that service, pass data in these method invocations, and receive the results asynchronously with a result handler.

As your application scales, it is likely that the number of services you wish to call will increase. It is also likely that your application will call a mixture of external services, including one or more HTTP services, web services, methods on Java classes, LiveCycle Data Services or any other services available to you. Likewise, different developers will have different uses for many of the same services. To solve this recurring challenge in Flex application development, the Cairngorm framework offers a pair of design patterns—once again borrowed from the J2EE community—to ensure consistency in how services are declared, how they are invoked, and how their results are handled within your RIA. These are the Service Locator pattern and the Business Delegate pattern.