Flash Remoting for J2EE Developers

Flash Remoting MX enables Flash MX clients running in a browser or on a user's desktop to access and invoke methods on server-side components running in a J2EE, Cold Fusion, or .NET application server. It is an essential piece of Macromedia's toolset for creating Rich Internet Applications. These applications are deployed over the Web and provide a desktop-software-like interface to server-side application features.

This article is targeted toward J2EE developers. It requires some familiarity with Macromedia Flash and its ActionScript scripting language. Flash developers building interfaces to J2EE applications will also benefit from the information provided here.

How Flash Remoting for J2EE Works

For those unfamiliar with Flash Remoting MX, the quickest way to get started is to download evaluation versions of Flash Remoting MX, Flash MX, and the Flash MX Remoting Components from Macromedia. If you download JRun 4, Flash Remoting is included. Macromedia has done a good job of providing simple examples and introductory documentation with Flash Remoting.

Flash Remoting for J2EE depends on features in the Flash MX player, a couple of ActionScript libraries for the Flash MX player, and a Java servlet that runs in the application server. Installing the Flash Remoting Components provides the ActionScript libraries and installing Flash Remoting for J2EE provides the servlet and supporting classes that run in your application server.

The Flash MX player handles serializing and deserializing ActionScript objects to and from a proprietary binary data format called Action Message Format (AMF). AMF serialized objects are the payload of HTTP requests and responses sent between the Flash MX client and the application server.

The client-side ActionScript libraries provide the ActionScript objects that a Flash developer uses to connect to and invoke methods on components in the application server. They also provide objects that are helpful for debugging the connection.

In a J2EE application server, Flash Remoting consists of a single servlet, flashgateway.controller.GatewayServlet, and supporting classes. The servlet and supporting classes are commonly referred to as the "gateway." The gateway uses introspection to locate and invoke methods on Java objects.

A typical lifecycle of a Flash Remoting call is:

1. The Flash client connects to the gateway.
2. The Flash client names a server-side component on which it wants to invoke a method.
3. The Flash client invokes a method on the server-side component, optionally providing arguments.
4. The Flash player issues an HTTP request that identifies the component and method to invoke and contains the arguments serialized in AMF format.
5. The gateway receives the request and deserializes the AMF objects into Java objects.
6. The gateway uses introspection to locate and create the named object and invokes the identified method passing the deserialized arguments.
7. The gateway serializes the method return value (or thrown exception) into the AMF format.
8. The gateway constructs and sends an HTTP response to Flash, including the serialized result.
9. Flash receives the response and deserializes the return value to an ActionScript object.
10. Flash invokes a callback defined by the Flash developer to indicate that the method invocation has returned.

Macromedia provides a UML sequence diagram of this lifecycle.

Flash clients may invoke methods on regular Java objects, EJBs, and servlets. In the Cold Fusion and .NET implementations, a Flash client may also invoke methods on web services proxied by Flash Remoting. In J2EE implementations, a little work is required to enable web services communication.

How To Best Use Flash Remoting and Why

With the above description of Flash Remoting, we are ready to get into the details.

Install Flash Remoting in a Web Application

Because the Remoting gateway has to locate and invoke methods on classes in your application, a class loader that has access to your classes must load it. While Macromedia is somewhat vague on the issue, I strongly recommend installing Flash Remoting for your application by:

1. Locating flashgateway.jar in the flashgateway.ear or flashgateway.war files installed by the Macromedia installer.
2. Placing it in your web application's WEB-INF/lib/ directory.
3. Mapping the gateway for your web application by adding the following to your web application's WEB-INF/web.xml file.

  <servlet>

    <servlet-name>FlashGatewayServlet</servlet-name>

    <display-name>Flash Remoting Servlet</display-name>

    <description>Servlet-based plugin to Flash Remoting</description>

    <servlet-class>flashgateway.controller.GatewayServlet</servlet-class>

    <load-on-startup>10</load-on-startup>

  </servlet>



  <servlet-mapping>

    <servlet-name>FlashGatewayServlet</servlet-name>

    <url-pattern>/gateway</url-pattern>

  </servlet-mapping>

This will make the Remoting Gateway Service available at http://www.yourdomain.com/yourwebapp/gateway. All classes in your application will be visible to Flash Remoting. Because Flash Remoting is installed as a servlet, it can be installed in any J2EE application server that supports servlets 1.2+, including but not limited to Caucho Resin, Jakarta Tomcat, BEA WebLogic, IBM WebSphere, Sun One AS, ATG Dynamo, and Oracle 9iAS.

Use a Service-Oriented Architecture

While you can directly access and invoke methods on servlets, JSPs, and EJBs with Flash Remoting, it does not mean that you should. It is important here to consider what Macromedia is doing today, what they are likely to do tomorrow, and where enterprise application development is going in general. In all of these areas, Service-Oriented Architectures feature heavily.

A Service-Oriented Architecture describes an application designed to expose a set of loosely-coupled business services that may be accessed by a range of clients to assemble application functionality. Clients may be J2EE or .NET applications or Flash clients. This architecture makes the applications providing the services flexible and scalable.

Enterprise application developers are rapidly adopting Service-Oriented Architectures, using web services to communicate between applications. The EJB 2.1 specification will require that all J2EE application servers provide the ability to expose Stateless Session Beans as web services. .NET already relies heavily on web services.

This all suggests that Macromedia released Flash Remoting as an intermediate step toward allowing Flash to communicate via web services. Developers should heed this trend toward Service-Oriented Architectures and use Flash Remoting to support a Service-Oriented Architecture that can easily be moved to web services in their own applications.