Flash Remoting Demystified

Macromedia recently released a server-side extension to Flash MX called Flash Remoting. Flash Remoting greatly simplifies the process of connecting Flash movies to a web application server to provide dynamic Flash content. Anyone who has developed dynamic Flash pieces using Flash 4 or 5 knows the tedious process of using the loadVariables command, bringing in raw data in a string of URL encoded text or XML that would require some marshaling on the client side before it could be used. While the end result may have been the same, Flash Remoting is a superior way to go about it for 3 reasons:

1. It saves time on the authoring end. Flash Remoting keeps your data, in the form of simple variables, query recordsets or arrays, in the same format throughout the process, eliminating the need for extensive juggling.
2. It saves bandwidth. Flash Remoting uses a binary format known as ActionScript Message Format (AMF) for transmitting data to and from the server, which greatly reduces its bandwidth requirements over previous methods.
3. It goes easy on the processor on the client side. Previous data juggling was done within the Flash player, which runs on the client computer. This would affect the speed of your animations, and was something out of your control. Now most of the data processing can be handled by the usually more robust server.

Flash Remoting enables you to connect directly to any WSDL-based web service built using Macromedia ColdFusion MX, Microsoft .NET, Java or SOAP. In short, Flash Remoting is Macromedia�s brave attempt to make Flash into a front-end web application development tool, and they�ve done a great job. Now all that remains is to figure out how to use it.

Development with Flash Remoting can be broken up into 3 parts:

1. Installing Flash Remoting
2. Creating web services you want to access via Flash
3. Setting up your Flash movie to access those web services

Installing Flash Remoting

Flash Remoting requires installation on the authoring side, and in some cases, on the server side as well. This may not be worth mentioning, but some developers may assume that having a copy of Flash MX is all that�s required to use Flash Remoting. It�s not. The Flash Remoting package, starting at $999, includes Flash MX authoring tool add-ons, as well as the server-side gateway software required to use Flash Remoting on .NET and J2EE (except JRun 4) servers. JRun 4 and ColdFusion MX contain native Flash Remoting capabilities and require no additional server-side installation.

Note: When Flash Remoting is deployed with ColdFusion MX, only ColdFusion-based web services can be called directly.

Creating Your Web Service

Rather than get bogged down with one of the various backend programming languages used to create a web service, let�s take as our example a web service that is already created. We�ll use the Currency Exchange Service, a web service posted to XMethods, which converts one currency into another. The description for this page is located here.

As the description explains, the function getRate receives the parameters country1 and country2, and provides the value of 1 unit of country1’s currency valued in country2’s currency.

The path to this web service, as noted at the top of the page, is http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl.

Accessing Web Services from the Flash Player

In the Flash authoring environment, we now set up our Flash Remoting connection and define our functions. A good practice is to put all this code in the actions of frame 1.

1) Include Flash Remoting components

We start by including the two files NetServices.as and NetDebug.as, two main Flash Remoting components. These files, and the others they refer to, contain built-in objects which communicate with Flash Remoting.

#include "NetServices.as"
#include "NetDebug.as"

NetDebug.as enables the NetConnect Debugger. Once the development process is complete, it is a good idea to comment out the inclusion of NetDebug.as.

2) Create the gateway

The Flash Remoting gateway is a translator between the Flash player and the web services we want to access. For our example, our Flash Remoting gateway will reside on a server running ColdFusion MX. By default, ColdFusion MX sets a virtual servlet mapping for Flash Remoting as your domain plus “flashservices/gateway”.

NetServices.setDefaultGatewayUrl("http://www.yourdomain.com/flashservices/gateway");

Note: Flash Remoting will only work if your Flash movie is hosted on the same domain as your gateway.

Now that we've defined the gateway, we�ll create our Gateway Connection object.

gatewayConnection = NetServices.createGatewayConnection();

Aside from the specific URL for your Flash Remoting gateway, these two lines of code are standard.

3) Create the service object

Now you set the URL to your web service as we define our service object. In our case, this will be the path to our Currency Exchange Service as described above.

currencyConverter = gatewayConnection.getService("http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl�);

If you want to connect to multiple files containing multiple functions, you can specify them all in the same manner:

myWebServices2 = gatewayConnection.getService("http://www.foo.com/webservices");
myWebServices3 = gatewayConnection.getService("http://www.bar.com/webservices");

And so on.

4) Create a responder

Before you can call a remote web service, you first need to define what to do with the results of this function call. This requires a responder.

currencyConverter_responder = 
{
	onResult:function (data)
	{
		trace (data);
	},
	onStatus:function (error)
	{
		for (i in error)
		{
			trace (i + " : " + error[i]);
		}
	}
};

First we define the name of our responder, in this case “currencyConverter_responder.”

Next we define what to do with valid results. When data is received from the server, onResult:function is automatically called. Between these brackets, we define what we want done with our result. In this simple example, we�ll just send it to the Flash output window through a trace command.

We also define what to do in case of error. If a server-side error occurs, onStatus:function is automatically called. The result of this function is “error,” an object with four properties: level, description, code and details. The for…in action sends all four properties to the Flash output window for debugging.

5) Call the function

We�ve set up the gateway connection, created our service object and defined what to do with the results. Now what�s left is calling the web service itself.

function convertIt (country1, country2)
{
	currencyConverter.getRate (currencyConverter_responder, country1, country2);
}

In this example, I�ve wrapped the web service call in a Flash function called convertIt. Like the actual web service getRate, this function receives the two variables country1 and country2.

It then calls the web service. Our web service, getRate, is a child of the service object currencyConverter which we defined earlier. You could store multiple web services within a single service object.

When calling this web service, in addition to passing the required variables country1 and country2, we first need to pass the name of the responder which will handle the results, as defined in the previous step.

This function will request data from the web service getRate. On receiving results, it will call the responder currencyConverter_responder. The responder will return to the output window the value of 1 unit of country1�s currency valued in country2�s currency.

It�s as simple as that. Basically, once you�ve set up your Flash Remoting gateway, accessing your web services is no different from accessing native Flash functions.

Conclusion

As more a designer than a programmer, I initially found Flash Remoting to be quite unwieldy as I waded through the technical documentation. However, once these basic steps of setup were explained to me, I found the technology made dynamic Flash development profoundly simpler than before. However, there are some bugs in the current implementation that may slow you down e.g. improper marshalling of some complex objects. These bugs all have workarounds, so there is no reason not to use Flash Remoting today. I expect once Flash Remoting comes into common practice, it will no doubt provide the missing link for a whole host of new Flash-powered web applications to revolutionize the Web.