Flash Remoting-a new network application development model

Flash Remoting-brand new network application development model

Development Mode of Flash Remoting
I have been looking for a better development mode since I started Java website background development three years ago. Although many website development methods have different development languages, their forms have not changed much.
Whether you use Perl, PHP, ASP, JSP, the actual process is roughly like this.

1: The user goes to your site, enters the information, and clicks the "Submit" button
2: The user waits for a response from the server. The browser loads the response page, and the user can view the result.
3: if there are more than one page of the result set, the user will click the next page. Submit the search result to the server again. The server program will search the result again and return the second page to the user's browser.
4: So reciprocating.

In general, it is the development method of request/response/session. If you are used to developing desktop applications, you will not get used to this method at the beginning, two key technologies, component technology and event-driven development, have long been lacking in website development models. Traditional website development technology involves three words: request, response, and session. No matter what language or technology is used, applications cannot be developed based on event drivers and components. Although SUN recently released JSF to try to add event-driven development methods to J2ee, it shows that the effect is poor. Now there are some good component development attempts, such as Apache's Tapestry, it uses a component to block the request/response/session from the developer's perspective and replace it with object/method/property, developers do not need to know the existence of request/response/session. Instead, they need to develop their own components in an object-oriented manner and use them to assemble their own web pages, it features component development methods and excellent separation of MVC (I personally think MVC is the best among many frameworks ), but it does not solve another very important problem-event-driven development. Event-driven development is very common in desktop application development. It is not unfamiliar to anyone who has used C/S development tools such as VB and Delphi. Why is event-driven in B/S development mode. The reason is that the "stateless" feature of the http protocol, the server treats every request from the browser as a completely new user, in order to maintain the status information, many application servers provide "state management", that is, session management. This gives end users the illusion of seamless integration, as if each request is identified by the server as a request from a specific user. The most famous example is the shopping box of the shopping website. Based on this situation, it is very difficult to adopt event-driven development, and HTML pages are not suitable for event-driven development. Every time the returned results are large or small, the entire page will be refreshed, this development method is also very inefficient, resulting in a waste of Bandwidth Resources. Increasing Session management on the server will also increase the waste of server resources.

Currently, there are only two technologies that use event-driven and component models to develop websites: ASP.net and Flash Remoting. I am not familiar with the former. For server-side technology, it is too dependent on Microsoft, and the client is also dependent on Microsoft. In general, it is a proprietary technology. Flash Remoting is a Macromedia company. The front-end technology depends on the company's Flash, while the back-end technology relies on Macromedia. Why do we say that Flash remoting technology is composed of two parts, the front-end is developed using the Flash + Flash Remoting component, and the back-end adopts the Flash remoting gateway + any later technology. Flash Remoting gateway now has many development source code implementation methods. In this way, Flash Remoting has many options on the server side.

Let's see what Rlash Remoting is.

Simply put, FLash remoting allows Flash to directly call the Remote Process on the server. Server-side development does not require any correction to adapt to Flash. It can adopt any language and technology and use the best design mode to design the server-side program without using any Flash APIs, with Flash remoting, The Flash program can call any remote service.

The Flash remoting gateway is The most important technology on The Flash Remoting server. It is installed on The application server and serves as an interface between The Flash player and The application server. It mainly performs three tasks.
1: Send Flash Player requests to the server
2. Translate requests and data from the Flash player into requests and data from the server.
3: translate the server response and data into the local data type of The Actionscript.

The communication protocol used between Flash Player and Flash gateway is a binary AMF (Action Message Format) developed by Macromedia. It is a lightweight and efficient protocol, it can be quickly serialized, deserialized, and transmitted between the two. In fact, if you are familiar with SOAP, you will find that this Protocol is re-constructed for SOAP in many cases. You can think that AMF is the binary version of Macromedia. Why does Macromedia recreate the wheel?
First, Soap is based on XML, which is too cumbersome or "Heavyweight" compared with binary AMF. Second, AMF is mainly designed and optimized for the Actionscript type, it is much more efficient in parsing and serialization than the common protocol format SOAP. Flash player 7 supports SOAP, while FLASH 6 supports SOAP through Flash remoting gateway.

To sum up, Flash remoting consists of two parts: Flash remoting component (client) + Flash remoting gateway (server ).

The Flash remoting component (client) is mainly used by developers to develop Flash remoting programs. The Flash remoting gateway (server) is used to translate the process calls from the Flash player to the server, translate it into a request Call recognized by the application server. The server then returns the result to the Flash remoting gateway, which then returns the result to the Flash Player in AMF format.

Maybe some people still don't understand it. Isn't Flash remoting allowing you to directly call the service on the server side? What are the advantages of Flash 5 + XML development. In fact, the most obvious thing is that with Flash remoting, developers no longer need to write XML parsing programs on the client and server. In addition, it can convert a large number of complex data types and automatically process data conversion between the Event code and the server. The use of AMF to serialize data is much more efficient than to process the serialization of strings such as XML. Of course, the consistent way to provide access to background services is also the biggest one. No matter what technology is used in the background, the frontend access method remains unchanged.

It is also worth mentioning that the Flash remoting method for processing sessions is transparent to users and servers. Session information is actually included in every AMF package without Session management. Because Flash is usually loaded with the browser at a time, the Session state is automatically maintained in each call to the server since then, and the Session information is kept in Flash, so there is no major difference between the server cluster or not.

Flash instance programming Step by Step.

If you talk too much about the theory, it is better to use a specific example to understand what Flash remoting is. It is not a step-by-step demonstration. I will explain the server environment running Flash Remoting. As mentioned above, the Flash remoting server can adopt various technologies. Macromedia recommends two products, Coldfusion and Jrun, of its own company. The underlying layer of Coldfusion is also based on Jrun, however, it is easier to develop and supports Flash remoting to access Coldfusion Web pages and components. However, the price is relatively expensive (tens of thousands of RMB), while Jrun is an Application server strictly certified by Sun j2ee, and the price is relatively low, with only over 700 US dollars, therefore, if the company uses Flash Remoting for development, I personally think Jrun is a great value. Of course, if you don't want to pay for application servers, there are still many free open-source solutions, such as PHP projects.Www.amfphp.org) And Perl ProjectsWww.simonf.com/flap) For Java openAMFWww.openamf.orgIt is a very good open-source solution. If I have the opportunity, I will write a detailed article to describe this open-source project. I am a Java programmer. The following example uses Macromedia's Jrun server for development. For details about Jrun download and related knowledge, refer to the Macromedia Website.Www.macromedia.com/software/jrun /? Promoid = home_prod_jr_100803.

A) establish the environment

I want to create a new Jrun service application to distinguish it from the existing Jrun servers admin, samples, and default, and create an application through jrun.
Start JRun Launcher, click admin Jrun Server, and click "start" to start the Server. The port number is 8000, so we can use the Jrun Management Console.

Start the Jrun Management Console. The following page is displayed.

Click "Create New Server" at the top"

A new window appears for creating a new Jrun Server. Enter flashremoting in "Jrun Server Name". Jrun automatically updates the content of "Jrun Server Directory" based on your input. Click "Create Server"

Wait for a moment, Jrun will prompt that the creation is successful, and output information such as the port occupied by the new server (allocated by Jrun). If you are not satisfied, you can modify it.

If you are satisfied with the setting, click the "Finish" button. If you are not satisfied with the setting, you can modify the Port number and click "Update Port Numbers" to Update it.

Open the resource manager and check that Jrun has created a new Flashremoting directory for you under the Server directory.

B) Develop the server program

First, create a new classes directory under the SERVER_INF directory of the created flashremoting directory.

Jrun supports FLash to directly call multiple J2ee technologies. The simplest is java class, Java beans, JMX, and EJB. Here is an example of Java Beans. Create the following Java bean file in the newly created classes directory:

package com.eiffelqiu.remoting;
public class TestBean implements java.io.Serializable {

    private String testvalue = "test";
    /**
     * Returns the testvalue.
     * @return String
     */
    public String getTestvalue() {
        return testvalue;
    }
    /**
     * Sets the testvalue.
     * @param testvalue The testvalue to set
     */
    public void setTestvalue(String testvalue) {
        this.testvalue = testvalue;
    }
}

People familiar with Java will find that this is a very simple Java bean, and even constructor is omitted, but the most critical part of this program is that I mark the red part, that is: java bean must implement Serializable. If you do not implement this interface, you will not be able to retrieve the value you just set. To maintain the status information, you must implement the serialized interface. Some examples of Flash remoting on the Internet omit this, which may cause some examples of Flash calling java bean to fail.

Go to the classes directory and compile the program in the command line: javac *. java-d.

All of our server programs are complete. You may think that this is too simple. In fact, this is a strong official Flash remoting. The server program only needs to focus on its own technology and does not need to know any Flash technology, flash remoting gateway is responsible for translation and conversion between Flash Actionscript objects and server objects. The server only needs to provide a service interface. This technology is very well divided, especially for large projects. According to the Macromedia Flash Remoting development model, there should be three main roles: Flash designer (designer, responsible for the interface), Flash Programmer (client Programmer, responsible for Flash remoting client programming ), server Programmer (various technologies can be used ).

C) Develop client programs

The Flash program on the client is not very troublesome. Create the following client. fla Flash program.

As shown in, there are six text boxes and two buttons.
I will list the naming Rules separately
The top text box is filled by the user. The var variable name in the text box is named sendText.
The button next to it is a Movieclip, Instance name: SetButton (click to send the sendText value to the server's JAVA Bean)
The following large text box is used to return server information. The var variable name in the text box is named responseText.
The button next to it is a Movieclip, Instance name: GetButton (click to feed the service segment information to the text box)

The following two text boxes are respectively set: Gateway path and Class Object Path.

The variable name in the text box corresponding to the gateway path is gatewayPath.

The two text boxes corresponding to the object path are objectPath.

Here I have set the default names for both of them.
Localhost: 8101/flashservices/gateway and com. eiffelqiu. remoting. TestBean

These are the flash gateway address of the Jrun server I just created and the full path name of the created JavaBean (the service name in Flash remoting ), you may notice that the port number I provided here is 8101, which is the port number of the newly created Jrun service.

After careful observation, you will find that I have placed an Action layer for writing code. However, when you open the script code at this layer, you will find that I only prevent one statement

#include "client.as"

　　

Tip: Why do I do this? Many Flash programs do this. The main reason is to prevent reverse engineering Flash from obtaining the source file. Some people can obtain the FLA source file from the SWF file through some anti-compilers. So there are a lot of Flash developers put their code on the outside, so that some web programs, such as JSP can be placed in the WEB-INF directory during deployment, in this way, users cannot directly access these addresses through the web site, but only programs can access them, so as to prevent reverse engineering directories. This kind of thing is just for your reference.

Now let's create a client. as file under the directory of the Flash file we just created

The file is as follows:

# Include "NetServices."
//:::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: ::::
//: Button Action Script
SetButton. label = "Set value ";
SetButton. clickHandler = function ()
{
NetServices. setdefagategatewayurl (_ root. gatewayPath );
ServiceConnection = NetServices. createGatewayConnection ();
ServiceObject = serviceConnection. getService (_ root. objectPath, this );
ServiceObject. setTestvalue (_ root. sendText );
}
GetButton. label = "Get value ";
GetButton. clickHandler = function ()
{
NetServices. setdefagategatewayurl (_ root. gatewayPath );
ServiceConnection = NetServices. createGatewayConnection ();
ServiceObject = serviceConnection. getService (_ root. objectPath, _ root );
ServiceObject. getTestvalue ();
}
//:::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: ::::
//:::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: ::::
//: Define data handler

GetTestvalue_Result = function (result ){
// Output message header
_ Root. responseText = "server response:" + result;
// Trace ("result:" + result );
}

//:::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: ::::

The code is very simple. Set the tag name for the two buttons and create a processing function. The Flash remoting method is fixed. First, set the default gateway address, the value localhost: 8101/flashservices/gateway we set in the gatewayPath text box, and then call NetServices. createGatewayConnection () establishes a connection with the flash gateway on the server. Using NetServices. createGatewayConnection () to call the service is the Java bean we created. The address of the bean is transmitted through the objectPath variable in the text box. Then call getTestvalue

        NetServices.setDefaultGatewayURL(_root.gatewayPath);
        serviceConnection = NetServices.createGatewayConnection();
        serviceObject = serviceConnection.getService(_root.objectPath, _root);
        serviceObject.getTestvalue();

Flash remoting programming has a naming rule for the default response function. For example, if the name of the function you call is getTestvalue, you can directly set getTestvalue_Result for your response function, in this way, you do not need to set a feedback object and set the Response Function in it.

Start our Flashremoting server first.

Open JRun Launcher. If you have already opened it, click "refresh" and you will see that the flashremoting you just created appears in the Jrun server list. Select it and click "Start ".

Run the FLash program, enter "Hello Flash remoting" in the first text box, click the Setvalue button, and then click the Getvalue button.
You will see the corresponding content from the server in the text box:

"Server Response: Hello Flash remoting"

This is a complete example of Flash remoting. You may think this example is too simple. Flash Remoting can make more complex programs, it does not impose any restrictions on the technology used on the server, but simplifies data transmission between Flash and server technologies. The above example is just a brief introduction to the traditional Flash remoting technology, the new Flash remoting for Flash mx 2004 acionscript 2.0 adds more things, and many writing methods have changed. I will introduce them in future articles.