Introduction

Flash Remoting is a technology that enables you to easily connect your Flash movie to a server-side back end. Prior to Flash Remoting, the only options for transferring data were through XML or URL-encoded data strings, both of which require you, the developer, to serialize and deserialize the data on both the client and server. The terms serialize and deserialize refer to the process of formatting complex data so that it can be transferred between programs, and then translating the serialized data back into the appropriate datatype. For example, consider the scenario in which you want to pass an ActionScript array from Flash to a server-side script using LoadVars. To do this, you have to first convert the array into a string (serialization). Here is an example of a serialized array in which vertical pipes are used as delimiters between elements:

myArray=val0|val1|val2

Not only do you have to serialize the data before sending it, but you have to deserialize it in the server-side script to convert it back into an array. Furthermore, the data may not be correctly interpreted when it is deserialized. XML and URL-encoded strings allow you to send string data only. So, for example, if your array has Boolean values and you serialize it as follows:

myArray=true|false|true

when you deserialize it, the resulting array will be an array of strings with the values "true", "false", and "true". Furthermore, although arrays are fairly simple to serialize, other datatypes, such as recordsets, can become much more complex.

The problem of transferring data between applications is not unique to Flash, and many different solutions exist. One such solution is WDDX, an XML-based language that describes both simple and complex datatypes. WDDX is supported in many programming languages, including ActionScript (if you download Branden Hall's WDDX ActionScript file available from http://chattyfig.figleaf.com/~bhall/code/wddx_mx.as). However, the downside with WDDX is that, although it handles the nitty-gritty details of serialization/deserialization, you still have to manually instruct your application to perform these tasks.

Flash Remoting is Macromedia's answer to this dilemma. Flash Remoting is supported for ColdFusion MX, .NET, and J2EE. For details, see http://www.macromedia.com/software/flashremoting. Additionally, there are third-party implementations: AMFPHP for PHP (http://amfphp.org), FLAP for Perl (http://www.simonf.com/flap), and OpenAMF for Java (http://www.openamf.org). Whatever the server-side implementation, I refer to it as the Flash Remoting gateway, or simply the gateway.

Flash Remoting uses a proprietary message format called action message format (AMF) for sending data between Flash movies and server-side applications. As a developer, you never have to see the AMF messages, since the Flash Player (on the client) and the Flash Remoting gateway (on the server) perform the serialization and deserialization for you, automatically and transparently. Flash Remoting knows how to convert between ActionScript datatypes and the appropriate server-side datatypes. This chapter necessarily assumes you have some familiarity with the server-side platform on which you intend to use Flash Remoting. For more information, refer to the resources cited in appropriate recipes.

In addition to the server-side implementation of Flash Remoting, you'll also want to download and install the free Flash Remoting Components available from Macromedia at http://www.macromedia.com/software/flashremoting/downloads/components. The term "Components" is slightly misleading. You will not be installing any Flash components, but rather a handful of .as files in the Flash Include directory. These files define important ActionScript classes you'll need to harness the power of Flash Remoting. Simply download the file appropriate for your platform and unzip it. You should automatically be prompted to save the .as files to the correct directory (the Include directory in the Flash installation).

Whenever you use Flash Remoting, you must include the NetServices.as library file, which contains the code necessary to connect to a Flash Remoting-enabled server from Flash. If you do not include NetServices.as, the example does not work; however, you do not receive any errors within the authoring environment.

Once you have the server-side software (a valid gateway) and client-side software (the Flash Remoting Components) set up, you are ready to get started with Flash Remoting. Of course, you'll also want to have a general idea of how Flash Remoting works. The Flash Player has a built-in class called NetConnection, which enables the Flash Player to send and receive AMF messages. Therefore, it is possible for the Flash Player to send messages to a server-side script that is configured to listen for and accept messages (the gateway) and for the server to send messages back to Flash. Using AMF messages, you can actually instruct the gateway to invoke server-side functions and return the value (if any) to Flash. When invoking server-side functionality with Flash Remoting, there are two terms you should be aware of:

Service

A service contains the functionality you want to invoke. For example, a ColdFusion Component (CFC), a JavaBean, or a .NET assembly can contain methods that you want to invoke from Flash Remoting. Therefore, these constructs are referred to as services.

Service function

A service function is the remote function that you want to invoke from Flash. For example, the methods within a CFC, a JavaBean, or a .NET assembly are all service functions.

Table 20-1 shows the types of services and corresponding service functions for ColdFusion, J2EE, and .NET.

Table 20-1. Flash Remoting services and service functions

Server	Service	Service function
ColdFusion	Directory	ColdFusion page
ColdFusion	CFC	CFC method
ColdFusion	Web service	Web method
J2EE	Context	JSP or servlet
J2EE	Java class	Public method
J2EE	JNDI for EJB	Public method
J2EE	MBean	MBean method
.NET	Directory	ASP.NET page
.NET	Assembly	Public method
.NET	Web service	Web method