When you hear the term "Flash Remoting", you might be wondering what exactly is being referred to. If you are in that boat, this article is for you.
Macromedia's latest push towards the Rich Internet Application has at its core the Flash Remoting technology. This article will give you a brief introduction to Flash Remoting and the related technologies and show you the necessary requirements to getting it up and running on your machine and your web server. We will also show the most basic HelloWorld application and how to make it work in ColdFusion, ASP.NET, and Java.
Flash Remoting is a server-side technology that allows a Flash developer to call remote services from within the Flash movie that reside on an application server. What do I mean by this? Suppose your Flash movie needs to send an email. You might have a server-side service named Email, and a method named send(). You would call it directly from the Flash movie like this:
myEmailService.send(theEmail);
That is the power and simplicity of Flash Remoting: the ability to seamlessly integrate services that reside on your application server with client-side code written in ActionScript. This opens up a whole new world for Flash developers. Now, instead of having to translate XML or name/value pairs of data inside the Flash movie, you can call the server-side service by name and have it return a value or an object as if it were a simple client-side function. Also, the technology creates the illusion of a seamless integration of your Flash movie with an application server. When you are working with Flash Remoting you sometimes forget that the functions you are calling are not in your Flash movie -- they are on the server. It really makes the communication that easy.
So now you are saying to yourself "what are these services that I keep hearing about?" Well, the term service in this case simply refers to a file on your server. A service might be a ColdFusion Component (CFC) page, an ASP.NET DLL, or a Java class. In addition, you can use any SOAP-based web service as a Flash Remoting service. Services are at the heart of Flash Remoting. You can create these services or utilize pre-built services. In the Email example used above, the service might be a file named Email.cfc on a ColdFusion server with a function named send().
Flash Remoting consists of two parts: the client side components and the server-side gateway. The server-side gateway is preinstalled with ColdFusion MX and JRun 4, and is available as a commercial product for Java servers such as Tomcat and Websphere, and is available for ASP.NET as well. The commercial gateway is also available as a free download as a developer's edition.
To make Flash Remoting work you need these four things:
Flash Remoting Client Components
A compatible web/application server
Flash Remoting MX (server-side adapter)
In addition to these four requirements, you can also download or purchase several other key parts, such as charts and graphs, other client components, or the Firefly components.
The first piece of the puzzle is Flash MX. That is a given. You need Flash MX to build Flash Remoting applications. You cannot, however, build Flash Remoting applications using Flash MX without the addition of the Flash Remoting Client Components. This is a free download from Macromedia that adds several things to your Flash MX environment:
You also need an application server that is compatible with the Flash Remoting technology. At present, if you own ColdFusion MX or JRun 4, the Flash Remoting functionality is already built into the server. You do not need any server add-ons if you have one of these servers. At this time, the only supported platforms are CFMX, Java, and ASP.NET. Classic ASP users do not have an option for Flash Remoting.
If you are running ASP.NET or a Java server, such as Tomcat or Websphere, you can download a developer edition of the Flash Remoting MX package (server-side) for your application server. The commercial license for this package is around $1000. Still there are other options, such as a third party open-source version for PHP and a third-party open-source version for Java. These will not be addressed in this article.
Assuming you have all the pieces to the puzzle, there are a few items to go through to make sure you are set up for remoting:
Is my application server running? If you installing an application server for the first time, you should become thoroughly familiar with it before beginning to dive into Flash Remoting. For example, a ColdFusion MX server is a fairly easy install, but you should make sure that it is running properly before attempting to create a Flash Remoting application. An application server can usually be addressed by it's IP address:
http://192.168.0.4/
or by localhost, if it's a local machine:
http://localhost/
Some app servers will operate on a port other than port 80. If this is the case, you have to specify the port in order to access the pages on your application server:
http://localhost:8500 (ColdFusion MX uses this with the built-in web server)
http://localhost:8080 (Tomcat uses this URL by default)
Where do my files go? Part of the process of getting to know your application server is knowing where to put files that will be accessible to Flash Remoting. In general, a web root directory is created when you set up your app server. Files that will be accessible to your Flash Remoting application will reside in a folder in your web directory. On a test machine you will typically use the webroot and build subdirectories off of that. Flash Remoting services use the path and the filename of the remote service in your ActionScript code. This will be explained later.
What is my Flash Remoting gateway path? Flash Remoting requires that you specify the path to the Flash Remoting gateway in your Flash movie. This path will be different for all servers, and might even be different for different applications on your server. The following are some typical locations:
http://localhost/flashservices/gateway (ColdFusion running locally using IIS or Apache as a web server)
http://localhost:8500/flashservices/gateway (ColdFusion running locally using built-in web server)
http://localhost:8080/flashgateway/gateway (Tomcat running locally using a default installation)
http://localhost:8100/flashservices/gateway (JRun running locally using the default application)
http://localhost/myApplication/flashremoting/gateway.aspx (ASP.NET running locally using a subdirectory of myApplication)
http://www.mydomain.com/flashservices/gateway (ColdFusion running on your web site)
Don't be alarmed if you can't find the directory on your server. These locations are in many cases not physical locations on the server (except for the ASP.NET installation, where you will find a blank file.)
Is Flash Remoting working on the server? You can test the functionality of Flash Remoting using the URL of the Flash Remoting adapter. Paste it in your browser. If you see a blank page, Flash Remoting is working.
The first application everyone always writes when learning a new technology is the HelloWorld application. We'll do that for Flash Remoting as well. The application is about as simple as it gets, but contains all of the core concepts behind Flash Remoting:
The Flash ActionScript code for this will be very simple, but will show you all of the key parts required for a Flash Remoting application. We'll assume that you know how to open up Flash and use the Actions panel.
We'll also assume that you have a web directory on your server named FlashRemoting101 that will hold the service. The service is simply a file. The file will be named HelloWorld.***, where *** is the file extension of the technology you are using (cfc, aspx). The Java example will use a class in a new FlashRemoting101 package.
// *Step 1*
// Include the NetServices.as file. This is required for Flash Remoting
#include "NetServices.as"
// *Step 2*
// Set up your Flash Remoting path and service path
var myURL = "http://localhost/flashservices/gateway";
var myServicePath = "FlashRemoting101.HelloWorld";
// *Step 3*
// Set up a responder object, with an onResult method
// for the result and an onStatus method for any errors
myResult = new Object();
myResult.onResult = function(data){
trace("Data received from Server : " + data);
}
myResult.onStatus = function(info){
trace("An error occurred : " + info.description);
}
// *Step 4*
// Create the connection to the Flash Remoting adapter on the server
// *note: this just sets the URL in the Flash movie. No connection is made
yet
var myServer = NetServices.createGatewayConnection(myURL);
// *Step 5*
// Create an object to hold your remote service reference
// The getService() method takes two arguments here: the path and the responder
object
var myService = myServer.getService(myServicePath, myResult);
// *Step 6*
// Finally, call the method
myService.sayHello();
The ActionScript code is the client part of the client-server application. The server portion will either be ColdFusion, ASP.NET, or Java. The following files show how easy it is to create a server side service. As I said earlier, as service is simply a file.
Although here we are using service and file interchangably, the Flash Remoting implementation for Java allows you to use Java classes, JavaBeans, and other Java constructs as services. Similarly, the implementation for ASP.NET allows you to use ASP.NET DLLs as services. Those are beyond the scope of this article.
ColdFusion MX introduced CFCs as a new way to create ColdFusion functionality. We'll use a CFC named HelloWorld.cfc to create the service:
<cfcomponent>
<cffunction name="sayHello" access="remote" returntype="string">
<cfreturn "Hello World from ColdFusion Component" />
</cffunction>
</cfcomponent>
The component has its access set to "remote", which allows us to use it with Flash Remoting. The component has one method: sayHello(). This is what we are calling in the Flash movie. You can see that it simply returns a string to the caller. Our caller is the Flash movie.
The ASP.NET implementation will be a C# page named sayHello.aspx located in a directory at <webroot>\FlashRemoting101\HelloWorld. Notice the page name is the method name, and the folder name is the service name. This is different from the ColdFusion implementation where the component name is the service name. The code is as follows:
<%@ Page Language="C#"%>
<%@ Register TagPrefix="MyTag" Namespace="FlashGateway"
Assembly="flashgateway" %>
<MyTag:Flash ID="Flash" Runat="Server" />
<%
Flash.Result = "Hello World from ASP.NET page";
%>
Using a Java class is just as easy. Compile and save the class in the classpath of your application:
package FlashRemoting101;
public class HelloWorld{
public HelloWorld() {
}
String sayHello() {
return "Hello World from Java";
}
}
Assuming that you have created the Flash movie and created a service on your server, you can now run the application locally in Flash (Control > Test Movie). This is what happens:
Of course the complexity is hidden. All you do is call sayHello() and handle the result. The cool part of it is that even though this is a simple service, a more complex service will be just as easy to call.
Flash Remoting combines many different aspects, including client-side Flash development, server-side developement, and database development. Orchestrating the different technologies can be difficult at first, but the technology of Flash Remoting itself will make your life easier if you are building web applications that utilize Flash for a front end. More information can be found at http://www.macromedia.com/devnet/flashremoting.