About Flash Remoting MX for Java

How does Flash Remoting MX for Java work?

Flash Remoting MX exposes Java objects as services that are accessible from Flash applications as ActionScript functions that correspond to Java object methods. A Flash developer writes ActionScript that uses the NetServices ActionScript class to connect to a remote Java application server, get a reference to a service, and invoke the service's functions.

To transport messages, Flash Remoting MX uses a binary message format called Action Message Format (AMF) delivered over HTTP and modeled on the Simple Object Access Protocol (SOAP) used in web services implementations. AMF is smaller and faster than standard SOAP, and is purely asynchronous and event-driven. It lets you send a variety of data types, including RecordSets, Java objects, primitives such as integers, Strings, XML documents, references to EJBObjects, and Dates across the wire. For more information about AMF, see "Understanding AMF," in Chapter�1.

The Flash Remoting gateway is a front controller on the Java application server that handles the conversion of data types between ActionScript and Java.

When the gateway receives a service request, the request passes through a set of filters that handle such things as serialization, logging, and security, before arriving at a service adapter designed to handle the service and invocation type. Flash Remoting MX has adapters specifically designed for JavaBeans, Java classes, EJBs, JMX MBeans, and server-side ActionScript.

Where does Flash Remoting MX fit into the Java application architecture?

A design pattern is a solution to a recurring problem. Many design patterns are used in the context of a model-view-controller architecture, in which you separate data access functionality from the user interface and control logic that uses that functionality.

In design pattern terminology, a Flash application that uses Flash Remoting MX is the view portion of an application, much like a JavaServer Pages (JSP)- or servlet-based front-end is. The Flash Player, running in a web browser or in stand-alone mode, is the client in which the view is rendered. The Flash Remoting gateway is a front controller that translates interactions with the Flash-based view into actions that server-side Java objects perform.

Using Flash Remoting MX, you can take advantage of common design patterns and frameworks in which relational data is mapped to objects such as EJBs, JavaBeans, value objects, JMX MBeans, or Java Collections returned to the presentation tier. Flash Remoting MX for Java relies on these patterns of data transfer, rather than working with relational data returned directly to Flash.

In addition to using built-in data type mapping, you can pass any serializable object from Java to a Flash client. The Java instance's fields, including private fields, are converted to ActionScript properties on an ActionScript result object; when working with JavaBeans, this feature gives you access to JavaBean properties.

Two design patterns, the value object and session facade patterns, can be particularly useful with Flash Remoting MX. Both patterns can reduce the number of remote method calls required in a Flash application.

You can use a value object to send a coarse-grained view of data to the server and get back fine-grained data. For example, you can call a single method on a value object that aggregates several method calls on an entity bean. The method result is returned to the Flash application as an ActionScript result object from which you can access data locally. This pattern can help reduce network traffic and response time, and reduce the load on EJBs. For more information about the value object pattern, go to http://java.sun.com/blueprints/patterns/j2ee_patterns/value_object/index.html.

You can use a session facade to provide a single point of contact to a set of EJBs. For example, you can call methods on a session bean (the session facade) that is capable of calling various methods on several other EJBs, depending on the user's current context in the application. This pattern reduces network traffic and makes it easier to support different types of clients, change the enterprise data model, or change the server implementation. For more information about the session facade pattern, go to http://java.sun.com/blueprints/patterns/j2ee_patterns/session_facade/index.html.

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/flashremoting/mx/Using_Flash_Remoting_MX/usingFRJ2EE2.htm

Using Flash Remoting MX
Using Flash Remoting MX for Java