n part 1 of this series, I discussed various ways to connect a Flash application to a server. Why? Connecting Flash to a server allows for more robust, dynamic, and useful applications than is otherwise possible. More and more companies are replacing traditional Web applications on intranets, extranets and public sites with rich Internet apps, providing the interactivity and responsiveness of a client-server application with the fully distributed nature of an Internet application. To make this possible, it is necessary to integrate external data.
Introducing Flash Remoting
Flash Remoting allows data to be exchanged between a Flash Player and an application server using a format called AMF (ActionScript Messaging Format), which is a Macromedia proprietary binary format based on SOAP. On the client side, native Flash objects are sent by the Player to the Flash Remoting gateway using AMF. At the gateway, they are serialized into native objects for the application server and passed on to the appropriate server-side services.
Table 1 shows the serializations from Flash into .NET, Java, and ColdFusion data types, while Table 2 shows the serializations performed from the application server data types back into ActionScript.
Table 1. Serializing Data from Flash Objects
Table 2. Serializing Data into Flash Objects
|Array||Array, ICollection||Object, Array of primitive types, Collection, Map||Array|
|Number||Int, float, double||Number||Numeric|
|Object||HashTable||Throwable, flashgateway.io.ASObject, Dictionary, Serializable||Structure|
When results are returned, the gateway serializes them back into native Flash objects and sends them on to the Flash client via AMF. When the data arrives in Flash, it is already in native object format, so it can be used without any further translation. Further, all the data transfer between the client and server is done in AMF over HTTP, so there are no new firewall restrictions for Flash applications using Remoting.
There are two pieces needed to use Flash Remoting: The Flash Remoting gateway (also called the Remoting Server) and a Flash application into which the Flash Remoting components are compiled. In the next section, I’ll discuss how each of these pieces work, as well as the basics of AMF, then, later, I’ll try out Flash Remoting with a simple application.
Flash Remoting Gateway
The Flash Remoting gateway is a server-side object, installed into either a Java (including ColdFusion) or .NET server. In the Java world, the gateway is actually a servlet, while in .NET it is an .aspx file. The gateway is responsible for brokering requests between Flash and the server as well as translating between Flash objects and the native objects for the server on which it is running.
The Flash Remoting gateway is built into ColdFusion, JRun, and Flex servers (all Macromedia products) and is available for purchase from Macromedia for .NET or other Java servers.
|Figure 1. Opening the Remoting Libraries: The Remoting Libraries can be accessed through the Common Libraries menu.|
ActionScript Messaging Format (AMF)
All communications between the Flash client and the gateway are done using AMF. AMF is like a binary version of SOAP, allowing for smaller data sets to be transferred between the client and server. One key difference between AMF and SOAP is that the data is describing objects specifically for Flash, as opposed to the generic “platform agnostic” descriptions that would actually occur with SOAP. This works, as the Flash Remoting gateway very efficiently translates Flash objects into those usable in .NET or Java.
Flash Remoting Components
To allow a Flash application to use Remoting, the Flash Remoting components need to be compiled into the application. These components are available free and can be downloaded from Macromedia. Macromedia recently rewrote these components, so they can now be used more easily, and directly mirror the other data components, such as the WebServiceConnector and XMLConnector components.
Once these components are installed in Flash Studio, they can be dragged into a Flash movie and used like any other component.
The NetConnection Debugger
Among the things installed with the Flash Remoting Components is the NetConnection Debugger. This debugger allows developers to see the full details of all data sent between the client and server. This can save a great deal of time when troubleshooting dynamic applications, as developers do not need to guess at the content of the data being sent back and forth, nor do they need to write their own debugging code, as they would with Web services.
To use the NetConnection debugger, the debugging classes need to be compiled into the libraries and the debugger needs to be initialized. Both tasks are very easy to do. To include the Remoting Debug Classes, choose Window > Other Panels > Common Libraries > Remoting from the top menu, as shown in Figure 1.
|Figure 2. The NetConnectionDebugger Panel: The NetConnectionDebugger will show both parameters sent from Flash to the server as well as the details of the data received.|
Next, drag the RemotingDebugClasses symbol from the Remoting library into the library for your application. Once the class is available, it needs to be initialized through code. You can do this by opening the actions panel and typing:
Be aware, it’s always a best practice to remove this debugging framework before going to production; the NetConnectionDebugger can expose more data to end users than most developers would prefer. All that is needed to remove the debugging is to simply delete the RemotingDebugClasses symbol from the library.
Before testing the movie, open the NetConnectionDebugger panel. This can found at Window > Other Panels > NetConnectionDebugger. With the debugger initialized and open, any Remoting traffic between the client and server will show in the panel, as seen in Figure 2.
Using Flash Remoting
Using the FlashRemotingConnector components is no more difficult than using the WebServiceConnector components as discussed in the first article. To demonstrate this, I’ll use the same application from that earlier article and modify it to use Remoting instead of Web services.
Figure 3 shows the application interface, this time with RemotingConnector components in place of the WebServiceConnector components. With ColdFusion as the server, no changes need to be made to the server-side code to switch between Web services and Remoting.
|Figure 3. The Interface: The sample application uses a simple interface with two list boxes, three RemotingConnectors, a Button, and two text fields.|
For each connector, use the component inspector to set the properties including the gateway address and the object and method names (see Figure 4).
Once the properties are set, all that remains is to trigger the components and handle the results. Again, this is identical to the process used for Web services. Listing 1 shows the full source code for the Remoting version of the sample application, the Radio Free Astoria song requestor module.
Assuming a simple interface (see Figure 2) of two list boxes, a text field, a button, and three RemotingConnector components drawn on the stage in Flash, the ActionScript in Listing 1 defines the corresponding functionality. The handleEvent method routes all the broadcast events to their appropriate handlers.
This code directly mirrors the code from the first article that used Web services (see Listing 2 ), with the only differences being the inclusion of NetDebug initialization at the beginning and the use of RemotingConnectors instead of WebServiceConnectors. The application functions identically, except the data transfer between client and server is significantly faster.
How much faster? In comparing performance of the “Song Requestor” application using Web services (see http://www.devx.com/webdev/Article/21803/0/page/3) to the same application using Flash Remoting in this article, the time between triggering the connection to the server and when usable data was returned is five times longer with Web services. In local testing with Flash Remoting it took an average of 608ms between triggering the getArtists method and when the Artist ListBox was populated. Triggering the same method using Web services took an average of 3182ms before the ListBox was populated. Independent testing of other applications has shown similar results.
|Figure 4. Set It Up Right: The component inspector is used to set the URL for the Remoting gateway, as well as to specify the object (servicename) and method (methodname) that will be used.|
Benefits of Flash Remoting
Both Web services and Flash Remoting offer developers the opportunity to connect and exchange data with objects on the server. The main difference between the two is that the Flash Remoting server handles the work of translating between Flash data types and those used by the Application Server, while Web services require the Flash Player to handle all the data parsing.
Flash Remoting was introduced with the release of Flash MX, prior to the support for Web services with Flash. At that time, Remoting was the only means available to connect a Flash client to a remote object. With the release of Flash MX 2004 and the support for Web services it brought, many believed that there was no longer a place in Flash applications for Remoting.
In fact, that couldn’t be further from the truth. While Web services offer an alternative, Flash Remoting remains the recommended means to connect a Flash client to an application server. The Web services alternative is there for those who do not have access to a Flash Remoting Server, however, those who do have a choice between Flash Remoting and Web services will be rewarded with much greater performance using Remoting.