Enhance your J2EE presentation layer

Flash Remoting introduces an alternative J2EE presentation layer

When selecting a presentation layer technology for any n-tiered architecture, Java developers are usually left with two choices: JSP (JavaServer Pages) or a Swing/AWT (Abstract Windowing Toolkit) solution. JSP gives Java developers the ability to create dynamic content that is extremely easy to distribute. However, developers must give up a certain degree of control over how their application will run when delivered in various browsers. Swing gives developers the ability to control most aspects of an application's behavior, but requires that users install a Java runtime. Cases exist where developers need to both distribute their applications as small, browser-based deliverables and maintain a high level of control over user interactions. In these cases, Macromedia Flash provides an alternative solution.

Traditionally, Macromedia Flash has excelled at delivering feature-rich applications with small footprints. Unfortunately, until recently, no standard method was available for integrating Flash applications into J2EE (Java 2 Platform, Enterprise Edition) architectures. That situation has changed with the introduction of Flash Remoting MX. Flash Remoting MX provides a standard communication layer for Flash applications to communicate with Java, .Net, and ColdFusion application servers. By utilizing Flash Remoting, a developer can distribute a small, browser-based presentation layer to a J2EE system, while maintaining plenty of control over the application's behavior.

This article will examine where Macromedia Flash fits in the recent evolution in presentation layers for n-tiered systems. I start by examining how presentation layers have recently changed, then compare Flash to existing standards, and finally examine how Flash fits into a J2EE system.

The evolution of presentation layers

Ever since Tim Berners-Lee created the first Web-based system, presentation layers for n-tiered systems have undergone a revolution. Before that time, developers were forced to create client systems tightly coupled with their corresponding servers. Using only the basic HTTP protocol, a Web server, and HTML, developers were able to deliver document-based applications to users, regardless of what hardware or software platform they used. This approach had some fundamental problems for application developers: while HTML succeeded at delivering document-based data, it proved unsuitable for creating rich applications—applications with ample real-time feedback for users.

To address these shortcomings, developers began exploiting some of the features available in modern (post Netscape Navigator 2.0) Web browsers, namely Java and JavaScript. For the first time, developers were able to leverage the Web browser platform as a delivery mechanism for rich, platform-neutral applications. The actual user experience of using applets, however, never really matched the expectations. Applets required users to already have the Java Runtime Environment (JRE) installed and a Java Plug-in for their Web browser. In addition to the steps needed to set up a client system to execute Java applets, the client machine needed to download the actual Java applet. This could often prove time consuming, especially over slower Internet connections.

Out of this evolution grew three main choices for developers to use when deciding on a rich front end for their client/server applications: dynamic HTML (DHTML), applet/Swing, or a third-party solution. Each has its own benefits and drawbacks.

DHTML

Using DHTML to create a rich front end offers the following benefits:

  1. DHTML is open and free
  2. Applications written using DHTML can deploy in any Web browser with built-in DHTML support
  3. Web-based applications typically consist of text and images rendered on the client side, which allows for a small application footprint

DHTML is not always a perfect solution; a few drawbacks must be considered when selecting this technology:

  1. DHTML relies on the user's Web browser to faithfully render the application according to the developer's wishes. Due to the numerous variations between Web browser brands and versions, workarounds must be added to complex applications so they will behave uniformly across different browser implementations.
  2. Though DHTML affords application developers increased control over client-side behavior, developers are still limited in what they can do.
  3. Due to small differences in how various Web browsers render HTML and interpret JavaScript, workarounds must be created for each supported Web browser. Adding workarounds and separate implementations for each browser increases the complexity of maintaining an application. In addition, whenever a new Web browser is released, an application (or parts of an application) must be retested and recoded.

The DHTML approach really excels when a developer knows he will be deploying an application on a standard client base. If an intranet application will be developed for use with only Internet Explorer 6.0, the application logic can be tailored to that browser's behavior.

Applet/Swing

For Java developers, an applet- or Swing-based solution is another viable solution. This approach offers the following benefits:

  1. Creating a Java-based application is free for both the user and the developer
  2. Applets can deploy through most Web browsers
  3. Applets allow developers to create rich user interfaces
  4. Applets offload some of the processing power from the server to the client

Choosing to use an applet-based solution should be weighed against the following drawback: A developer cannot assume that users have installed JRE. If they do have JRE installed, it might not be the required version.

Applets represent a great choice for Java developers deploying their applications on a standard client base. With a standard client base, a developer can assume that the correct JVM version will be present.

Besides using an applet/Swing or a DHTML application, developers have one more choice: a third-party solution.

Third-party solutions: Macromedia Flash

To compete with a DHTML or applet solution, a third-party product would need the following attributes:

  1. It should be deliverable through a standard Web browser
  2. It should require almost no user intervention to run an application
  3. The client runtime should be free or inexpensive
  4. The client should be able to integrate with existing backend business logic

A few third-party solutions compete in this space, including Apple's QuickTime, Microsoft's ActiveX, and Macromedia's Flash Suite. All three solutions are readily available on many users' systems. All three can deliver an application through a Web browser at no cost to the user. Flash, however, offers a significant benefit for Java developers over both ActiveX and QuickTime: it allows the client application to invoke methods on any J2EE application server. This means that existing business logic contained in EJB, (Enterprise JavaBeans) servlets, Web services, and classes can be invoked by a new Flash-based front end without any backend changes.

A server-side product called Flash Remoting enables Flash clients to invoke methods on a J2EE server. Flash Remoting consists of two main components: a gateway server used to map native Flash objects and methods to Java objects and methods, and client-side support. The gateway application comes in a standard war file, deployable on any J2EE application server. The client-side support comes in the form of added functionality to ActionScript, the native programming language used by the Flash runtime and development tools.

For Flash Remoting to work, a Flash application must connect to a J2EE server, obtain a handle to the service (the Java object) that it wishes to utilize, and invoke a method. This is done by using the ActionScript library called NetServices. The following example obtains a connection to the gateway, which resides in a Web application named MX, with the following servlet mapping in the web.xml file:

   <servlet-mapping>
      <servlet-name>FlashGatewayServlet</servlet-name>
      <url-pattern>/gateway</url-pattern>
   </servlet-mapping>
//Load the NetServices ActionScript Library
#include "NetServices.as"
//Create a connection to the mx webapp running on port 80 on the local 
//machine
NetServices.setDefaultGatewayUrl("http://localhost/mx/gateway");
//Invoke the createGatewayConnection to initialize the Flash Remoting //functionality
gatewayConnnection = NetServices.createGatewayConnection();
//Bind the Java Object: com.tallan.data.providers.FlashDemo 
//to a service called tallanDataService.
tallanDataService = gatewayConnnection.getService("com.tallan.data.providers.FlashDemo", this);
//Invoke a method called getReportData on the service named 
//tallanDataSerevice
tallanDataService.getReportData();

This trivial example is all that is needed to connect to a J2EE application server and invoke a method.

To handle any real work, parameters must pass back and forth between the Flash client and the enterprise resource living on the J2EE server. All Remoting calls are handled in an asynchronous method. To support return values from the server, a callback method must be added to the Flash client. This callback method will invoke whenever the gateway returns a result from the method call on the J2EE server. To support the method callback, the ActionScript function name must correspond to the Java method being invoked. In this example, that method is getReportData(), so the ActionScript callback method must be called getReportData_result:

function getReportData_Result(result)
{
   //Print the results from the app server to the
   //debug window
   trace(result);
}

All method invocation information, including parameters and return values, pass between the client and server in Action Message Format (AMF). AMF is a binary message format delivered over HTTP in a manner similar to SOAP (Simple Object Access Protocol). On the wire, an AMF message is much smaller than a SOAP message, which allows for the method invocations to be significantly faster. Flash Remoting transparently handles all mapping between Java objects and ActionScript objects.

One of the most significant attributes that makes Flash a good candidate for J2EE front ends is its built-in XML parsing ability. Flash can natively handle XML parsing and DOM (Document Object Model) traversing all on the client's machine. The following ActionScript code parses an XML document that contains x and y coordinates for use in a 2D graph:

<graph>
   <point>
      <xvalue>10</xvalue>
      <yvalue>5</yvalue>
   <point>
   <point>
      <xvalue>20</xvalue>
      <yvalue>10</yvalue>
   <point>
</graph>

A simple class on the application server generates this graph document:

public class FlashDemo
{
   public FlashDemo() 
   {
   }  
      public Document getReportData()
      {
         Document doc =null;
         try
         {
            System.out.println("calling getReportData");
            DocumentBuilder builder = 
               DocumentBuilderFactory.newInstance().newDocumentBuilder();
            doc= builder.newDocument();
             
            //Create a record as the root element
            Element element = doc.createElement("graph");
            Element child1=doc.createElement("point");
            child1.setAttribute("xvalue", "February");
            child1.setAttribute("yvalue", "20");
            element.insertBefore(child1, null);  
            doc.appendChild(element);

This simple class will return a Document object to the Flash client for parsing; the example below completes the parsing:

1 2 Page 1