10.2 Why Use Flash Remoting?

One of the common questions about Flash is whether you can access web services using the Flash client only. Although Flash Player 6 requires Flash Remoting to access web services, Flash Player 7 has built-in SOAP support. However, the basic Flash 2004 authoring tool does not include the SOAP-based components that are standard in Flash Pro. Therefore, you must use Flash Pro (instead of Flash 2004) if you intend to use the built-in SOAP features of the Flash Player 7. As of this writing, it isn't clear how Macromedia will prevent developers from extending Flash 2004 to support the SOAP enhancements available in Flash Pro. Licensing restrictions and encrypted libraries have been raised as possibilities.

Table 10-1 summarizes the compatibility issues.

So, should you switch to SOAP-based web services or stick with AMF? The answer is "it depends." If you need to support Flash Player 6 or access any web service outside your domain, you'll need Flash Remoting (or an open source equivalent) installed on the server side. If you want to use a SOAP-based solution without Flash Remoting, you must wait for Flash Player 7 to infiltrate the installed base. Within 18 months of its release (September 2003), Flash Player 7 should have sufficient penetration (greater than 80%) to justify shipping a SOAP-based solution, even if you're using a J2EE or .NET server without Flash Remoting. If you want to develop Flash applications that access SOAP-based web services from Flash Player 7, you must upgrade to Flash Pro because the basic Flash 2004 authoring environment doesn't include the libraries or prewritten behaviors for SOAP-based web services.

The major advantage of using SOAP is that J2EE and .NET servers understand SOAP messages without requiring Flash Remoting to be installed on the server side. This is very attractive if you don't have the privileges to install Flash Remoting on the server. So, when using J2EE and .NET, should you always use SOAP-based web services? Not necessarily. For one thing, you'll want to wait until Flash Player 7 is widely installed in the user base. Furthermore, the AMF format is more compact and efficient for transferring binary data, so Flash Remoting may yield better performance than SOAP-based web services. If you decide that Flash Player 7 is sufficiently ubiquitous to drop support for Flash Player 6, should you use SOAP-based web services when communicating with ColdFusion, JRun, or PHP? Not necessarily. ColdFusion and JRun come with Flash Remoting preinstalled, and it is a free installation for PHP. There is no reason not to use AMF format if you can guarantee that the Flash Remoting gateway is available on the server, as it is in these cases. (Likewise, the free OpenAMF Java implementation makes sense for developer's who have shied away from Flash Remoting for J2EE due to cost.)

Until you switch to Flash Player 7 and SOAP-based web services, you must use the Flash Remoting adapter on the server in order to translate your web service into an AMF packet that Flash Player 6 can understand. So, let's return to using SOAP-based web services in Flash MX. In many cases, this is as simple as adding the Flash Remoting adapter URL into your Flash movie. No hand-written server-side code is necessary. The Flash Remoting adapter on the server takes care of the necessary translation, so your Flash movie can simply use the service. Figure 10-1 shows a diagram of how Flash Remoting fits into the picture.

Figure 10-1. Flash Remoting and web services

This is the order of operations:

Why wasn't Flash Player 6 built to utilize SOAP directly? There are several reasons for this:

• SOAP is a large protocol. It is based in XML and requires major parsing inside of the Flash plugin. Flash Player 6 excluded SOAP support in order to keep the plugin footprint small and accelerate deployment. Adding SOAP deserialization to Flash Player 7 increases the footprint over Flash Player 6 somewhat.

• The Flash Player has security restrictions that prevent it from loading content from other domains. This is a good thing, as it keeps the level of acceptance of the Flash player very high; having Flash on your computer is regarded as safe.

• The AMF format of Flash Remoting is a terse binary format, which results in fast transfer speeds between the Flash Remoting gateway and the Flash movie. Furthermore, there is faster processing because of less serialization and deserialization.

As a contrast in size, look at the AMF response passed to the Flash movie for the simple HelloUser SOAP example shown earlier:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 01 Jan 2003 01:40:30 GMT
Cache-Control: private
Content-Type: application/x-amf
Content-Length: 59

......./1/onResult..null.......Hello Tom. It is 8:40:30 PM..

The Content-Length header tells the story: the SOAP version was 371 characters, whereas the AMF version was 59 characters. You can imagine that, with more complex web services, the savings in bandwidth can be enormous. Macromedia's reluctance to release the AMF specification hasn't dampened developer enthusiasm for the format in the guise of projects such as AMFPHP (http://www.amfphp.org) and OpenAMF (http://www.openamf.org).

There are other techniques to access a web service from Flash, such as parsing the SOAP on the server using server-side code, but Flash Remoting is by far the easiest method to use. This chapter discusses the different implementations of Flash Remoting and how to use web services in each.

10.2.1 Limitations

Using Flash Remoting for consuming web services is a viable option in many cases; however, there are a few limitations:

• Flash Remoting is able to connect only to SOAP web services that have a WSDL descriptor file. At this time, XML web services are not supported.

• You have to supply all of the parameters to a web service, even if they are optional parameters.

• Datatypes that aren't supported in your platform (ColdFusion MX, Java, ASP.NET, or PHP) aren't supported by Flash Remoting. For example, ColdFusion supports a Query datatype, but it is not accessible from ASP.NET because ASP.NET does not support a multidimensional array type.

Some of these limitations may be addressed in future versions of Flash Remoting.