Using Flash Remote Call Enhanced Java EE presentation layer

The remote invocation of Macromedia's Flash has enabled Java developers to build Java 2 Platform In addition to JSP (JavaServer Pages) and swing, Enterprise Edition) application. This article investigates the Flash remote invocation, explains why it works so well, and provides an example of how to implement it.

Java developers typically have two options for choosing the presentation layer technology in any multi-tier system: JSP or SWING/AWT (Abstract windowing Tookit). JSP enables developers to create dynamic content that is very easy to publish. But it also makes it difficult for developers to control their operations when applications are published in different browsers. With swing, developers can easily control the behavior of the application, but require the user to install the Java Runtime environment. This is also the case when developers need to publish both in a smaller, browser-based way and with greater controllability of user interaction. For these cases, Macromedia Flash offers an alternative solution.

Generally speaking, Macromedia Flash is richer than the publishing interface and is superior to applications with scripting programs. Unfortunately, until recently there was no standard way to integrate flash applications into the Java EE system. This situation changes with the introduction of Flash Remoting mx. Flash Remoting MX provides a standard communication layer to make flash applications with java. NET and ColdFusion communication. With Flash Remoting, developers are able to publish small, browser-based representations in the Java EE system, while allowing sufficient control over the behavior of the application.

This article explains why macro Flash is suitable for use as a solution to the application layer in an n-tier system. I will first investigate how the application layer can be changed, then compare flash and existing standards, and finally explain how flash is applied to the Java EE system.

Evolution of the Application layer:

Creating the first web-based system from Berners-lee so far, the presentation layer of the N-tier system has undergone a change. Prior to that, developers had to develop client systems that were tightly integrated with the server. Only basic HTTP protocols, Web servers, and HTML can be leveraged, and developers can publish documents based applications for users, regardless of the hardware or software platform they are using. This approach has some basic problems for application-tier developers: Although HTML can be successfully transmitted based on document data, it is not suitable for applications with multiple manifestations-it can interact with the user in real time.

To address these deficiencies, developers began to develop new features, Java and JavaScript, in modern browsers (after Netscape Navigator 2.0). For the first time, developers can use a Web browser platform to publish rich, platform-independent applications. In fact, the use of Java applets has never met its expectations. The Java applet requires that the user has installed the Java Runtime Environment (Java Runtime Environment, JRE), and that the Web browser has a Java plug-in installed. In addition to the need to install a client system to run Java applets, clients also need to download Java applets. These are time-consuming, especially if the connection to the Internet becomes very slow.

In addition to this workaround, developers have three options for using rich front-end in client/server applications: Dynamic HTML (DHTML), applet/swing, or third-party solutions. Each of these solutions has its pros and cons.

Dhtml:

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

1. DHTML is open and free

2. Applications written using DHTML can be configured in any Web browser that supports DHTML

3. web-based applications their clients are usually composed of text and pictures, which allows small application scripts to exist.