Section 11.1. The Remoting Gateway

11.1. The Remoting Gateway

The rest of this chapter focuses on the client code and techniques used in Flash Remoting, but let's take a moment to discuss the entire process. Flash Remoting enables you to make a request to the application server, have the server process the data using business logic, and return the results back to the client. The request/response system of Remoting works similarly to the technique of calling a remote FlashCom method, as discussed in Chapter 9. The process is asynchronous as well, so the results are not immediately returned but trigger an event in the client. However, unlike FlashCom remote methods , Flash Remoting calls use a non-persistent connection and use the HTTP protocol to communicate. Instead of sending RTMP data over the network, Remoting uses Action Message Format (AMF).

AMF is a binary message format modeled after SOAP, a protocol designed to exchange structured data in a distributed environment. SOAP uses XML tags to describe and package data and was designed to be abstract and versatile, which unfortunately resulted in the schema being complex and verbose. AMF was designed to be an efficient, compact format to pass ActionScript datatypes over the network. AMF uses binary flags to describe and package data. An AMF packet will always be smaller than an equivalent SOAP packet, which translates to faster response times and faster processing times when creating and processing AMF packets instead of SOAP.

Figure 11-1 depicts the process performed during a remoting call.

Figure 11-1. The process performed in response to a remoting call

When a request is made to an application server:

1. The client serializes dataincluding the parameters that the remote process expectsinto AMF data. That binary data is wrapped in an HTTP packet and sent over the network to the destination server.

2. The application server receives the request and passes it on to the Flash Remoting gateway, which converts the AMF data into native datatypes of the application server (something that the server can understand).

3. The application server performs the necessary processing and generates a response. The response is serialized back into AMF by the remoting gateway and wrapped in an HTTP packet and sent back to the client.

4. The client receives the results and deserializes the response AMF data into ActionScript objects.

There are several server-side implementations of the Flash Remoting gateway. Although Flash Remoting is not included with FlashCom, Macromedia bundles it with ColdFusion and JRun. Macromedia also offers Flash Remoting for separate purchase for J2EE and .NET. There are several open source implementations of Flash Remoting for PHP, Java, and Perl such as AMFPHP (http://www.amfphp.org), OpenAMF (http://www. openamf .org), and AMF::Perl (the remoting gateway formerly known as FLAP at http://simonf.com/amfpython). FlashORB (http://www.flashorb.com) is a third-party alternative. For extensive details on Flash Remoting, including its use with ColdFusion, Java, PHP, .NET, and Server-Side ActionScripta version that differs slightly from the SSAS supported by FlashComsee Flash Remoting: The Definitive Guide (O'Reilly).