7.8 Architecture and Design

Flash Remoting provides the means for Flash clients to communicate efficiently with server-side applications. When using Flash Remoting for J2EE, you are either building a new application with a Flash interface or adding Flash Remoting to an existing application to support a new Flash interface. In either case, you may be supporting both Flash and traditional HTML interfaces.

This section presents strategies for including Flash Remoting in your Java application architecture.

7.8.1 Use a Service-Oriented Architecture

Although you can directly access and invoke methods on servlets, JSPs, MBeans, and entity and session EJBs with Flash Remoting for J2EE, you shouldn't necessarily do so. If possible, you should avoid exposing Flash developers to the details of how you have implemented the application functionality. Instead, you should create JavaBean and Java class services that provide a simple, clean interface for Flash clients. Have the JavaBean and Java class services invoke methods of your application to provide those services to Flash clients.

A service-oriented architecture (SOA) describes an application designed to expose a set of loosely coupled business services that can be accessed by a range of clients to assemble application functionality. Clients may be J2EE or .NET applications or Flash clients. A service-oriented architecture makes for applications that are flexible, scalable, and able to collaborate with other applications running on the network.

Enterprise application developers are rapidly adopting service-oriented architectures. In the J2EE world, session EJBs are enterprise service implementations . Across technology platforms, SOAP-based web services are rapidly becoming a popular technology for supporting service-oriented architectures. The EJB 2.1 specification requires that all J2EE application servers provide the ability to expose Stateless Session Beans as web services. Microsoft's .NET architecture already relies heavily on web services. In addition, the major packaged application vendors , such as SAP, PeopleSoft, and Siebel, have announced support to varying degrees for web services and are providing SOAP interfaces to their core products.

Flash Remoting is designed to facilitate creating applications that use a service-oriented architecture to expose services to Flash clients. While Flash Remoting uses Macromedia's own AMF message format, the philosophy is very similar to SOAP-based web services. Expect Macromedia to leverage standards such as SOAP-based web services moving forward. For example, Flash Pro and Flash Player 7 have native support for SOAP-based web services in addition to AMF-based Flash Remoting.

Developers should use Flash Remoting to support a service-oriented architecture in their own applications. These applications will be flexible enough to be used by rich Flash clients to support traditional HTML-based presentation layers and to expose their functionality through web services.

7.8.2 Create a Business Delegate

To use a service-oriented architecture with Flash Remoting, simply create an object within your web application that is designed to explicitly expose services to Flash. Using another object to get the real work done is called delegation . In the terminology of the Sun J2EE Blueprints, such objects are Business Delegates . They can be used to present an encapsulated, Flash-friendly interface, exposed through the Flash Remoting gateway, that invokes methods on EJBs or any other object in the application server on behalf of the client. For more information on the Business Delegate pattern, see http://java.sun.com/blueprints/patterns/BusinessDelegate.html.

Using a Business Delegate addresses the need to create Remoting service methods that accept ASObjects as method parameters instead of business objects appropriate to your application. The Business Delegate has service methods that accept and return the known Flash Remoting object types. All that a service method needs to do is convert the Remoting objects, usually ASObjects , to application-specific objects, invoke methods on other application objects to get the work done, and convert the results back to Remoting objects for returning back to Flash.

In most cases, the Business Delegate can be a simple Java class service. Consider an application that has a Directory class that manages user information stored in User objects. Clients to a Directory object can retrieve users by name , update a user's data, and retrieve a list of all users. Here is a simplistic implementation:

 public class Directory {   static Map users = new HashMap( );   public static void updateUser (User user) {     users.put(user.getUsername( ), user);   }   public static User getUser (String username) {     if (!users.containsKey(username)) {       users.put(username, new User(username));     }     return (User) users.get(username);   }   public static Collection getAllUsers ( ) {     return users.values( );   } } 

The Directory class provides simple methods for creating, updating, and retrieving User objects. In this example, the Directory class stores User objects in a HashMap object in memory. In the real world, the Directory class would probably use a database for storage.

The Directory class cannot be used directly through Flash Remoting, because its methods accept and return native Java User objects, not ASObjects . The Remoting gateway will not convert method parameters sent from Flash into User objects, so the Directory class will not be able to find a service method with a matching name and parameters. The solution is to create a Business Delegate for Flash clients to access through Remoting.

The following example shows a Business Delegate for the Directory class, implemented as a Java class service called UserService . The UserService class has a method for each method in the Directory class but it accepts and returns ASObjects instead of User objects. The UserService class uses ASTranslator to convert ASObjects to User objects and then invokes a method of the Directory class with the same name. When a method of the UserService class obtains the results from a corresponding method of the Directory class, UserService converts the User objects back to ASObjects using ASTranslator again:

 public class UserService {   public void updateUser (ASObject asUser) {     User user = (User) new ASTranslator( ).fromActionScript(asUser);     Directory.updateUser(user);   }   public ASObject getUser (String name) {     User user = Directory.getUser(name);     return (ASObject) new ASTranslator( ).toActionScript(user);   }   public List getAllUsers ( ) {     Collection users = Directory.getAllUsers( );     return (List) new ASTranslator( ).toActionScript(users);   } } 

Usually, a Business Delegate strategy is sufficient to expose your application's features to Flash clients through Remoting while keeping your original application architecture intact.

However, in some cases, it is useful to have the Remoting service be stateful , meaning that an instance of a service persists between service method calls. JavaBean services are stateful. Consider the getAllUsers( ) implementation in the preceding example. In a real-world application, it is likely that the list of users is too large to efficiently return in one chunk to the Flash client. Using a JavaBean service implementation of the Business Delegate, we can provide simple paging features to the Flash client.

The following example shows a Business Delegate for the Directory class, implemented as a JavaBean service called UserService . The getUsers( ) method gives a Flash client an interface to page through the entire list of users, count users at a time:

 public class UserService   implements Serializable {   List users = null;   int index  = 0;   public List getUsers (int count) {     // Get the list of users if we don't have it yet     if (users == null) users = new ArrayList(Directory.getAllUsers( ));     // Based on   count   , determine the range of indexes for the list of users     int from = index;     int to   = index + count;     index += count;     // Get the sublist of users limited to the range     List result = users.subList(from, to);     // Convert the   User   objects to   ASObjects   and return the result     return (List) new ASTranslator( ).toActionScript(result);   } } 

The preceding example omits the obvious need for boundary checking and additional information for the Flash client, such as the number of users available, but it illustrates the utility of stateful JavaBean services. The Remoting gateway will persist a single instance of the UserService bean in the user session for a series of calls to getUsers( ) , so that the Flash client can request a small chunk of users at a time.

With Java class and JavaBean services, Java developers should be able to handle all service implementations for Flash clients. If you wish to expose a service available from a session EJB, create a Java class service that delegates to the session EJB. In the preceding example, the Directory class could be implemented as a session EJB that the UserService bean looks up in JNDI to handle the work of each service method call.

When integrating Flash Remoting with an existing application, the trick is to identify the services needed by the Flash client. It is possible that business logic that would support these services is combined with code that renders HTML views. In this case, refactoring is required to extract the business logic code to classes independent of presentation code.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. See Refactoring by Martin Fowler (Addison-Wesley). Refactor code to improve reusability and readability and to make it easier to make changes and add functionality.

The newly refactored classes will become the application services used by both the Remoting Business Delegate services and the presentation code to carry out their respective tasks .