ActionScript.org Staff

The http://ActionScript.org Staff are Jesse Stratford and Evgueni Strok. The original founders of this site in 2000, Strok and Jesse live thousands of miles from each other and have never met in person...

View all articles by ActionScript.org Staff

Copyright © 2004 O'Reilly Media, Inc. All Rights Reserved.
Programming Flash Communication Server
By Brian Lesser, Giacomo Guilizzoni, Robert Reinhardt, Joey Lott, Justin Watkins
February 2005
ISBN: 0-596-00504-0
http://www.oreilly.com/catalog/progflashcs/index.html
Available from booksellers or direct from O'Reilly Media, www.oreilly.com.

 Cover image
This content is excerpted from the above-named O'Reilly publication, with permission, by agreement with ActionScript.org.

Table of Contents

11.1. The Remoting Gateway
11.2. Remoting Basics
11.2.1. Remoting Classes
11.2.2. Passing Datatypes
11.2.3. Action Message Format
11.3. Role of Remoting in FlashCom Applications
11.4. Securing Access
11.5. Conclusion

Server-Side ActionScript (SSAS) supported by FlashCom 1.5.2 does not offer all the same features as client-side ActionScript. SSAS does not support the LoadVars or XML " name="progflashcs-CHP-11-ITERM-3596">Flash Remoting to communicate with an application server to accomplish these necessary tasks.

Flash Remoting has two parts: the client-side API used to create a connection to an application server and a server gateway that acts as the bridge between the client logic and the application server. The client-side APIs are built into the FlashCom Server as well as the Flash Player. This chapter discusses the entire Flash Remoting process but will focus on the client-side API used to connect to the application server. Throughout this chapter, the term client refers to either a SWF running in the Flash Player or a FlashCom application. That is, when using Flash Remoting with FlashCom, the FlashCom Server acts as the client. The techniques provided are valid for either situation.

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

The process performed in response to a remoting call

When a request is made to an application server:

  1. The client serializes data—including the parameters that the remote process expects—into 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 ActionScript—a version that differs slightly from the SSAS supported by FlashCom—see Flash Remoting: The Definitive Guide (O'Reilly).