Home / Developer Center / Blackboard Sample Application

Developer Center Article

Flash Remoting enables Macromedia Flash applications to integrate with server-side Java resources. Server code can be called, and data can be passed back and forth, with a minimum of programming effort. The Unified Modeling Language (UML) sequence diagram in Figure 1 provides a high-level view of how it works. (If you are unfamiliar with analyzing UML sequence diagrams, see the overview for an explanation.)

Figure 1: The Flash Remoting infrastructure sequence

After simple initialization, the Flash application's User Interface (UI) utilizes NetServices to access programs, also known as services services, elsewhere on the network. Services can be JavaBeans (stateful), Java classes (stateless), Enterprise Java beans, and Java Management Extensions (JRun 4 only). Services can also include .Net and ColdFusion resources. This article focuses on accessing Java.

NetServices is the part of Flash Remoting that runs with the UI. NetServices are interpreted by the UI just like ActionScript, so they are very easy to incorporate. When you use NetServices in conjunction with your Flash application, there are three powerful benefits:

1	NetServices allow your Flash application to connect to remote programs as if they were local, ActionScript programs. In Figure 1, the Flash application can call to NetServices using the same methods and parameters that are available on the (remote) service. The UI makes these calls using ActionScript, and NetServices relays the request to the remote Java program.
2	NetServices transforms, or serializes, service inputs and outputs. (Actually, it uses the Macromedia Flash Player to accomplish this.) Input data is translated from ActionScript to Java data types for consumption by the server. The reverse occurs for data returned from the server to the client.
3	NetServices handles client requests asynchronously. (Asynchronous request processing is not shown in Figure 1, but it is in Figure 2.) Rather than forcing the UI to wait for the reply, NetServices returns control to the UI program while the remote service request is being processed. When the service reply is received at the client, NetServices notifies the UI and passes along the reply data. This is radically different from the existing thin client application model. This process enables the creation of much more responsive thin client user interface programs.

Figure 2 provides a detailed view of how Flash Remoting works. Most of these interactions happen "under the covers", so you don't need to be concerned about the internal processes—it just works. But, if you want a deeper understanding of the processes behind Flash Remoting, see Figure 2.

Figure 2: Flash Remoting infrastructure sequence diagram. Note: The full scale version of this diagram is also available.

The UI uses NetServices to create a gateway connection object. This object represents a server on which remote services are available. The gateway connection object does not actually make any network calls, as its name suggests. It merely acts as a factory for creating service objects.

A service object represents a server-side resource, a JavaBean for example. In the case of JavaBeans, the service name is the Java class name. For EJBs, it is the JNDI name that identifies the bean’s home interface. When a service object is created, both the service name and the reply handler (a.k.a. responder) object must be provided. The reply handler object will be called when replies arrive from the server. (The code samples that follow will clarify this process.)

Figure 2 shows the UI explicitly creating a reply handler object. This is the most general solution, but it does not have to be done this way. For example, the object that creates the service object can also handle replies from the server. The Blackboard example described in this paper uses this approach.

The UI calls server-side resources through the service object. This object serializes (transforms to a bit stream) input parameters for network transmission. Then the object creates an HTTP request that transports the input data across the network, to the Flash Remoting gateway servlet. Information crosses through the network for the first time here.

The gateway servlet deserializes input parameters to Java objects. It creates the server-side service object using its default (parameter-less) constructor, and invokes the method requested by the client.

The service does its work, optionally returning a reply object.

The reply object is serialized from a Java type for transmission, and is returned on the HTTP session to the service object in the UI.

The service object deserializes the reply to ActionScript. The service object calls a method on the reply handler object, passing it to the ActionScript reply object.

And finally, the reply handler notifies the UI that the reply has been received. The communication loop is complete.

Next, we'll look at how Flash Remoting was used to build the Blackboard project.