Web Services in Flash

Flash MX 2004 Professional now has the ability to consume Web Services without the use of any other technology. The Web Services classes can create a schema directly from a WSDL file and automatically convert the XML data structures into native Flash data structures.

Flash cannot do anything with WSDL documents. Remember that a web service is really returning a specially formatted XML document by means of SOAP. To process XML, we usually have to write a series of complex looping structures to "walk through the XML tree" to convert the XML nodes into native Flash data structures. More information on how to do this manually can be found in Chapter 12, "XML and Flash." The Web Service classes in ActionScript as well as the Web Services Connector component will automatically convert the SOAP XML into native Flash data structures.

The XML object first appeared in Flash 5, but was written entirely in ActionScript and was really too slow to use for any practical purposes. The object became much more useable in Flash MX because the Flash engineering team converted the XML object into a native C++ object, which is the language in which Flash itself is written. This conversion vastly sped up the XML processing. However, we still had to write the complex code that would loop through the XML object and convert the XML into native ActionScript objects.

The issue of having to write the complex code to loop through the XML data structures was solved in Flash MX 2004 Professional. ActionScript 2.0, through the use of a schema, will automatically convert the XML into native ActionScript 2.0 objects. After the data is in the schema, we can use visual data binding or ActionScript to link the data to a dataset or directly to user interface (UI) controls. The Web Services classes in ActionScript have schemas that are set up to work with SOAP XML data returned from Web Services. The XML connector in Flash is designed to work with straight XML (not SOAP XML); you can find more information about the connector in Chapter 12. See Figure 13.3.

Figure 13.3. The schema converts the raw XML into native Flash data structures.

Lazy Decoding

As we have seen, all the web service parsing occurs in the Flash Player in Flash MX 2004 Professional. Because all the translation happens on the client, parsing the XML from the web service can be very resource intensive , even with all the performance improvements. The easiest way to deal with this is to parse the data in small chunks of XML data. Of course, this is not always possible, so ActionScript supports "lazy decoding," which defers the translation from XML to ActionScript until it is actually requested .

Within the process of lazy decoding, arrays are replaced with a new type of ActionScript object that acts similarly to an array, but that defers the processing. Lazy decoding takes this heavy client-side processing and spreads it out over a longer period of time to improve performance. Lazy decoding can be turned on and off by accessing the SOAP Call class.

Lazy decoding is always on and it works as follows : Whenever an array is received in the results property of the Web Services Connector component, the translation into an ActionScript array is deferred. The results property passed to the developer looks and acts like an array, but translates the XML data only when it is requested.

You request the data from the array by simply referencing the array by the index, as follows:

 myArray[index]; 

It is not possible to use a for-in loop to loop over the array because the for-in loop begins at the last index of the array, and lazy decoding defers the request for this item.

Web Services Sandbox Security in the Flash Player

All XML that is loaded into the Flash Player (including the web service XML) is subject to the security sandbox restriction. This feature prevents the Flash Player from accessing any data that falls outside the domain of the SWF. For example, if you publish an SWF to www.bostons.com , you will be able to access Web Services only from www.bostons.com . It is important to note that subdomains are not included, as was the case in Flash Player 6; in Flash Player 7, the domains must match exactly. This restriction is not in effect when you test an application in the authoring environment (or when you publish an SWF as an .exe file), but it is in effect when you deploy the SWF to a web server.

You can access data from a different domain, as long as that domain contains a policy file that says it can accept data requests from your domain. The policy file must be in XML format, in the web root, and look like this:

 <?XML version="1.0"?> <!DOCTYPE cross-domain-policy   SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy>   <allow-access-from domain="*" /> </cross-domain-policy> 

Note the asterisk in line 5; this indicates that any Flash movie from any domain can access the data in this domain. We could just as easily change the policy file to indicate that data can be received only from certain domains; in the following code, Bostons.com and Macromedia.com could access data only from this domain:

 <?xml version="1.0"?> <!DOCTYPE cross-domain-policy   SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy>   <allow-access-from domain="www.bostons.com" />   <allow-access-from domain="www.macromedia.com" /> </cross-domain-policy> 

N OTE

If you use Flash Remoting to connect to Web Services, there are no security sandbox issues because everything happens on the server and not in the Flash Player.