Remote data communication occurs at runtime. It does not reside strictly in the client, but requires network connections to send and receive data between the client and the server. Flex applications support a variety of remote data communication techniques built on standards. There are three basic categories of Flex application remote data communication:
- HTTP request/response-style communication
This category consists of several overlapping techniques. Utilizing the Flex framework
HTTPServicecomponent or the Flash Player APIURLLoaderclass, you can send and load uncompressed data such as text blocks, URL encoded data, and XML packets. You can also send and receive SOAP packets using the Flex frameworkWebServicecomponent. And you can use a technology called Remoting to send and receive AMF packets, which use a binary protocol that is similar to SOAP (but is considerably smaller). Each technique achieves the similar goal of sending requests and receiving responses using HTTP or HTTPS. See http://www.jamesward.org/census for a comparison of various methods for loading data at runtime over HTTP.- Real-time communication
This category consists of persistent socket connections. Flash Player supports several types of general socket connections: those that require a specific format for packets (
XMLSocket) and those that allow raw socket connections (Socket). In both cases, the socket connection is persistent between the client and the server, allowing the server to push data to the client—something that is not possible using standard HTTP request/response-style techniques. Flash Player also supports a real-time communication protocol called Real Time Messaging Protocol (RTMP). RTMP is used by a variety of server-side products, including Flash Media Server, Red5, FluorineFx, some versions of WebORB, and Wowza.- File upload/download communication
This category consists of the
FileReferenceAPI, which is native to Flash Player and allows file upload and download directly within Flex applications.
Of these three generalized categories, it is fairly easy to distinguish between file upload/download communication and the other two types. Clearly, file upload/download communication applies only to cases in which the application requires file uploading and downloading. However, the distinction between HTTP request/response and real-time communication is not always as obvious.
HTTP request/response is far more common than real-time data communication. Although real-time data communication is necessary for some low-latency applications, it adds network overhead to the application because it requires a persistent socket connection for each user. In contrast, HTTP request/response communication is always initiated by the client in the form of a request. The server returns a response to the client, and then the connection is closed again until the client makes another request. In most cases, the request/response model is more efficient. Furthermore, request/response over HTTP is generally less of a challenge to existing security models than real-time communication over persistent socket connections.
In this chapter, we’ll focus primarily on two forms of remote data communication: request/response and file upload/download. We’ll focus primarily on asynchronous (request/response) communication techniques because they make up the majority of remote data communication you’ll use for Flex applications. We’ll also discuss the basics of file upload and download.
When you build Flex applications that utilize data communication, it’s important to understand the strategies available for managing those communications and how to select the right strategy for an application. If you’re new to working with Flash platform applications, it’s important that you take the time to learn how data communication works within Flash Player and how that compares and contrasts with what you already know about developing for other platforms. For example, some of what you might know from working with HTML-based applications or Ajax applications may be useful, but you should never assume that Flex applications behave in the same way as applications built on other platforms.
As you already know by this time, all Flex applications run in Flash Player. With the exception of some Flex applications created using Flex Data Services, almost all Flex applications are composed of precompiled .swf files that are loaded in Flash Player on the client. The .swf files are initially requested from the server, but they run on the client. This means dynamic data (any data not statically compiled into the .swf) must be requested at runtime from the client to a server in most cases.
Because Flex applications are stateful and self-contained, they don’t require new page requests and wholesale screen refreshes to make data requests and handle responses. This behavior is something Flex applications have in common with Ajax. Rather than being page-driven, Flex applications are event-driven. Even as the view within a Flex application might not change, it can be making requests and receiving responses. Therefore, Flex data communication clearly requires different strategies from those employed by page-driven applications.
The Flex framework provides components for working with data communication using standard HTTP requests as well as SOAP requests. These components are useful when using the first of the common strategies for data communication: placing the code (the component) that makes a request within the class or MXML document that utilizes the data. This is often the most obvious strategy, and it is often the strategy that scales the least. This strategy decentralizes data communication, which causes several problems:
Managing data communication is difficult when the code is decentralized, simply because it makes it difficult to locate the code at times.
When data communication is tightly coupled with a particular view that uses the data, that data is not readily accessible to other parts of the application. This may not seem like a problem until you consider that many applications use the same data in many places, and if you place the data communication code within the views that use the data, you make it difficult to synchronize the data and you may require many requests for the same data.
Decentralizing data communication code makes the application fragile because changing anything about the data communication process (protocols, APIs, etc.) can break the application in many places. In contrast, when data communication code is centralized, it's relatively easier to adapt the application when something in the data communication process changes.
Although the first strategy has these significant pitfalls associated with it, we still include discussions of the components within this chapter because the strategy is not completely without merit. The components often provide a much faster way to assemble data-communication-ready applications. This is useful in cases of rapid prototypes, test applications, and small-scale (nonenterprise) applications with less demanding technical requirements.
The second strategy requires centralizing data communication using remote proxy objects. Remote proxies are objects that reside within the client tier where they can stand in for remote services. The remote proxy objects may even have the same APIs as the remote services. Remote proxies provide a centralized location for data communication code, and they hide the details of how data communication takes places from the rest of the application. Even if the implementation changes, the rest of the application can still continue to make calls on the remote proxy objects.
The second strategy is much more scalable than the first. Furthermore, because data communication code is centralized, this strategy is not susceptible to the same problems as the first strategy, such as duplication of data requests, synchronization problems, and adaptability issues. For these reasons, we strongly prefer the use of remote proxies for enterprise applications.