Enhance your J2EE presentation layer
Tutorial Details:
Enhance your J2EE presentation layer
Enhance your J2EE presentation layer
By: By Joseph Shomphe
Flash Remoting introduces an alternative J2EE presentation layer
hen 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:
DHTML is open and free
Applications written using DHTML can deploy in any Web browser with built-in DHTML support
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:
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.
Though DHTML affords application developers increased control over client-side behavior, developers are still limited in what they can do.
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:
Creating a Java-based application is free for both the user and the developer
Applets can deploy through most Web browsers
Applets allow developers to create rich user interfaces
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:
It should be deliverable through a standard Web browser
It should require almost no user intervention to run an application
The client runtime should be free or inexpensive
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:
FlashGatewayServlet
/gateway
//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 messag
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Enhance your J2EE presentation layer
View Tutorial: Enhance your J2EE presentation layer
Related
Tutorials:
 Understanding JavaServer Pages Model 2
architecture - JavaWorld December
1999
Understanding JavaServer Pages Model 2
architecture - JavaWorld December
1999
|
Solve your
servlet-based presentation problems - JavaWorld November
2000
Solve your
servlet-based presentation problems - JavaWorld November
2000
|
Develop n-tier
applications
using J2EE - JavaWorld December 2000
Develop n-tier
applications
using J2EE - JavaWorld December 2000
|
Add XML to your J2EE applications - JavaWorld February 2001
Integrate an XML presentation layer in the J2EE layered architecture
|
JSP best practices
Follow these tips for reusable and easily maintainable JavaServer Pages
|
Use Web services
to integrate Web applications with
EISs
Use Web services
to integrate Web applications with
EISs
|
Design patterns make for
better J2EE apps
Design patterns make for
better J2EE apps
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Rumble in the
jungle: J2EE versus .Net, Part
2
Rumble in the
jungle: J2EE versus .Net, Part
2
|
Java's secret weapon
Java's secret weapon
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Enhance your J2EE presentation layer
Enhance your J2EE presentation layer
|
Jump the hurdles
of Struts development
Jump the hurdles
of Struts development
|
J2EE 1.4 eases Web service development
J2EE 1.4 eases Web service development
|
The J2EE 1.4 Tutorial
The J2EE 1.4 Tutorial is a guide to developing enterprise applications for the Java 2 Platform, Enterprise Edition (J2EE) version 1.4. Here we cover all the things you need to know to make the best use of this tutorial.
|
Integrating Macromedia Flex with Java
Integrating Macromedia Flex with Java. Rich Internet Application (RIA) technologies are emerging to handle the limitations of the presentation layer. This article will teaches you Rich Internet Application development
|
J2EE pathfinder: Implement JSP custom tags in five easy steps
JSP custom tags provide a standardized mechanism for separating presentation and business logic in a dynamic Web page, allowing page designers to focus on presentation while application developers code the back end. In this installment of J2EE pathfinder,
|
Integrating Struts, Tiles, and JavaServer Faces
Integrating Struts, Tiles, and JavaServer Faces. Bring the power, flexibility, and manageability of the three technologies together.
|
The J2EE Architecture allows the programmers to divide their work into two major categories Business Logic Presentation
The J2EE Architecture allows the programmers to divide their work into two major categories Business Logic Presentation Logic
J2EE Architecture
The J2EE Architecture allows the programmers to divide their work into two major categories:
Business
|
Enhance your end-user MDI experience with JExplose
Enhance your end-user MDI experience with *JExplose* ! Extremely simple to integrate with your existing Swing MDI products.
|
|
|
|
