| The Flash Remoting gateway is installed on the application server and acts as an interface between the Flash Player and the server. The Flash Remoting software that implements the gateway is also called an adapter . It has three main tasks : -
Handle requests from the Flash Player to remote services. These services can be on the same server as the Flash Remoting gateway or can be external to the server in the form of web services. -
Translate requests and data from the Flash Player into server-side requests and datatypes. -
Translate responses and data from the server into native ActionScript datatypes. Figure 1-1 depicts the Flash Player/Flash Remoting architecture. Figure 1-1. The Flash Player/Flash Remoting architecture  Communication between the Flash Player and the Flash Remoting gateway is done via HTTP, which has a few implications: -
Communication between the Flash Player and the Flash Remoting gateway is request-driven. The Flash Player must initiate all communication with the Flash Remoting gateway. The server cannot push data to Flash unless it is requested by the Flash Player. Use the ActionScript XMLSocket object, as discussed in ActionScript for Flash MX: The Definitive Guide (O'Reilly), if you need to push data from the server to Flash, such as in a chat application. Another option is to use Macromedia's Flash Communication Server MX (FlashCom) for these types of applications. -
HTTP is a stateless protocol, so each request from the Flash Player opens a new connection to the server. The Flash Remoting gateway automatically maintains state between requests through the use of cookies. If cookies are not available on the client, the session state is maintained through a header in the communication packets between the Flash Player and server. -
Protocols that work with HTTP, such as SSL, also work with Flash Remoting. As shown in Figure 1-2, the client/server architecture is the same when the Flash Player communicates with Flash Remoting via HTTPS or SSL as it is using HTTP. Support for HTTPS allows communication between the Flash Player and the server to be encrypted using SSL, provided that the Flash movie is delivered to the client over an SSL connection and displayed within an SSL-enabled browser. This gives a Flash application the same level of security that is available to the HTML application. Figure 1-2. Flash Player/Flash Remoting architecture using SSL  1.2.1 Action Message Format Flash 5 movies could send XML or name /value pairs across HTTP. Although these packets could be parsed automatically by Flash or manually by the developer using custom ActionScript, parsing could be slow because all XML data is sent as text strings encased by cumbersome tags. Flash Remoting is able to handle complex datatypes, such as objects, structures, arrays, and recordsets. A proprietary format was needed to transfer information back and forth between the Flash movie and the application server. The protocol used for communication between the Flash Remoting gateway and the Flash Player is Action Message Format (AMF). AMF is a binary protocol designed by Macromedia to provide a lightweight, efficient means to serialize, deserialize , and transport data between the Flash Player and the Flash Remoting gateway, as shown in Figure 1-3. Figure 1-3. Flash Player/AMF/Flash Remoting  It is not necessary to understand AMF in detail to develop robust Flash applications that utilize Flash Remoting; however, it is useful to have a basic understanding of the protocol. Macromedia has not documented the protocol publicly , but the HTTP packets can be examined to gain insight into the format, which seems to be closely based on the format used in remote shared objects (RSOs). The developers of the AMFPHP project have partially documented the format at: - http://amfphp.org/?g=amf_format
The Flash Player communicates with the Flash Remoting gateway via the AMF protocol sent via standard HTTP requests. An AMF packet is sent as a binary POST with the body of the request containing the binary data serialization and remote procedure call information.  | Flash Remoting requires browser support for binary POST . Because Netscape 6.x does not support binary POST , Flash Remoting does not work when the Flash Player is running within Netscape 6.x. The Flash Remoting call has no effect and no error is returned. This bug is fixed in Netscape 7. There are also issues with early versions of Safari and Chimera on the Macintosh. You can use a browser-detecting script to redirect users to an appropriate page that uses HTML or older Flash formats if the user 's browser does not support your Flash Remoting application. | | An AMF packet consists of the following: -
A packet header , which describes the AMF version information and includes HTTP headers -
A count of context headers in the array that follows -
The context headers array , which describes to the server the context in which the information should be processed (on calls from the client) or describes to the client what is coming from the server (a result or status) and its format (such as a recordset or a string) -
A count of the messages in the array that follows -
The messages array , which is typically a method call coming from the client or a status/result coming from the server Following is the HTTP request and response generated by the Hello World examples shown later in this chapter. Because AMF is a binary format, the binary data is shown as periods ( .. .). The ASCII text in the following excerpt, such as amf_server_debug , is part of the literal message: POST /flashservices/gateway HTTP/1.1 Referer: http://192.168.0.5:8500/flashservices/gateway Content-Type: application/x-amf User-Agent: Shockwave Flash Host: 127.0.0.1 Content-Length: 198 Cache-Control: no-cache .......amf_server_debug....pNetDebugConfig coldfusion... amfheaders....amf.... httpheaders....recordset....error....trace...m_debug......... ....*com.oreilly.helloworld.HelloWorld.sayHello.../1.... And the response from the server back to the Flash Player is as follows: HTTP/1.0 200 OK Date: Thu, 23 May 2002 02:53:09 GMT Content-Type: application/x-amf Content-Length: 69 Server: JRun Web Server ..... /1/onResult...null..... Hello World from ColdFusion Component We can gain some insight into AMF by examining the request and response: -
The content type of AMF is application/x-amf . -
The AMF data is contained within the body of the request and response; it is primarily binary and is therefore difficult to show in print. -
There are human-readable strings within the AMF data. The last point tells us that AMF is not entirely compressed. However, even uncompressed, the protocol is very efficient at serializing ActionScript data. AMF has a number of advantages over traditional Flash data serialization techniques, such as XML and URL-encoded query strings, including: -
AMF is a binary format and thus creates serialized data that is smaller than using string-based encoding. This translates into lower bandwidth requirements and faster loading and response times. -
AMF was built specifically with Flash ActionScript datatypes in mind. Therefore, it can be serialized quickly and efficiently from ActionScript objects and deserialized into ActionScript objects within the Flash Player. In almost all cases, this leads to significant performance increases over string-based serialization. Why does Flash Remoting use AMF instead of SOAP to communicate with the Flash Player? After all, SOAP was designed as a lightweight protocol for the exchange of information in a distributed environment, which sounds similar to the goals for AMF. Both SOAP and AMF can transfer data and make calls on remote services, and both work over standard HTTP and HTTPS. There are several reasons why Macromedia developed AMF instead of using SOAP: -
SOAP is implemented as XML and is therefore rather verbose compared to the binary AMF. -
AMF is designed and optimized to work with Flash ActionScript datatypes. Deserializing AMF in the Flash Player is much more efficient than parsing and deserializing SOAP, because AMF has direct support for ActionScript datatypes whereas SOAP is a general-purpose protocol. Even if SOAP messages were compressed, serialization in AMF would still be more efficient. -
Adding AMF support to Flash Player 6 required only a small increase in the Player size (about 4 KB compressed), maintaining its slim footprint. -
Integrating full SOAP support on the client side, with acceptable performance, requires an increase in Player size. Although Flash Player 6 includes XML support, it does not support some headers required by SOAP. Using Flash Remoting, Flash can access SOAP-based web services even though Flash Player 6 doesn't support SOAP directly. That is, the Flash Remoting gateway translates SOAP requests to and from AMF format on the server-side and then uses AMF to communicate with the Flash Player. Flash Player 7 supports SOAP directly, but it will be late 2004 until Flash Player 7 is widely distributed. The body of the AMF packet contains either an onResult event (i.e., response event) or an onStatus event (i.e., error event), which are both ActionScript objects. The Flash movie can then use the object directly, without any further parsing. Chapter 3 contains an in-depth discussion of the onStatus and onResult events.  |
