Chapter 3. Using BlazeDS as a Server-Side Proxy
A Flex client often needs to access external sources of data. It can access this data using one of the following two mechanisms:
It can request for data and get it as a response.
It can register interest in a certain type of data and receive it if and when such data is available.
The first of these two options is "pull" based, whereas the second option is "push" based.
Off the shelf, the framework includes three methods of pull-based communication and data interchange with external data sources:
HTTP request-response is the most elementary of the three methods for external data access. It needs little preparation or prior knowledge to get started. I am assuming here that you know and understand the basics of the Web. Web services are not very complicated either, but they add a few additional protocols and semantics on top of the plain vanilla HTTP request-response. The last of the three, remote procedure calls using objects, is possibly the most complicated of the three. However, its complexity is often restricted to some initial configuration and the intricacies around the communication protocol, much of which is abstracted out for the application developer.
HTTP-based communication and web services can be leveraged by an application running in a Flash Player without BlazeDS or any such remoting layer, provided that the security constraints are satisfied. In other words, if the data source domain is the same as the one that serves the Flex application or if the external data source domain defines a security policy that allows for access from the Flex client, then often there is no need for BlazeDS. Such security policy is defined in a file named crossdomain.xml. The sidebar "Crossdomain.xml" explains what this XML file contains.
Crossdomain.xmlTo avoid cross-site scripting and hijacking of trusted network data from untrusted networks, Macromedia defined a security policy file for the Flash Player back in 2003. This security policy file is crossdomain.xml. The security policy when deployed at the root of a domain could allow access to its data from Flash applications served from other domains. Such access policies could be defined in the file as follows: <?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control
permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*"
headers="SOAPAction"/>
</cross-domain-policy>In the preceding example, the use of wildcard in the allow-access-from-domain element gives data access to all external domains. Alternatively, access could be restricted to specific domains by specifying them as values of this element. Policy restrictions apply to browser-facilitated HTTP and TCP/IP socket connections. Information on the security policy specification is available online at www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html. |
However, security restrictions may not be the only reason for using the BlazeDS proxy service. The proxy service supports HTTP methods beyond GET and POST, allows for state management in web services, and provides an opportunity to intercept all calls and their results to pass them through a desired business logic chain or apply cross-cutting application-wide concerns. These can be reasons as well for its usage.
In this chapter, you will learn to use the proxy service in the context of HTTP service and web service. HTTP service is simpler of the two, so that's where I will start.