|By Dennis Baldwin||
|October 20, 2004 12:00 AM EDT||
Flash MX 2004 Pro Web service classes or Flash Remoting components for ActionScript 2.0: Which is right for you? This article offers some guidelines.
In just three years we've come a long way. It seems like an eternity since the days when I used to code CF pages with dynamic content served up to Flash, but let me stress how rudimentary it was. Flash back to December 14, 2001, when a little site called FlashCFM received Macromedia's Site of the Day designation. On several occasions I received e-mails asking me how on earth FlashCFM received this prestigious award. There was nothing spectacular about the site, no fancy graphics, Flash animation, or anything out of the ordinary. Yet the concept behind it was brilliant, or so I believed. As you can probably guess from its name, this site introduced the marriage of Flash and ColdFusion.
FlashCFM was a community site that educated developers about the power of Flash and ColdFusion integration. When I say that this process used to be rudimentary, let me give a quick example of ColdFusion code in a page called variables.cfm:
So the output would look like:
Flash would then retrieve this data and display it with a simple line of code:
A very simple framework indeed (more like a CSV screenscrape or accessing a query string), but it proved to be the start of something wonderful. Flash forward to the present and we have such powerful technologies as Flash Remoting and Web service components. In this article I will go into detail about the pros and cons of each solution, as well as give you enough information to decide which is the best fit for your project. This will be demonstrated with a simple application that calls identical service methods, one using Flash Remoting and the other using the Web service classes. Enough history, let's get started!
Flash MX Pro Web Service Classes
If you've opened Flash MX 2004 Pro, then you're probably aware of the new Web service classes. Macromedia has done a great job in releasing components that allow Flash developers to easily consume Web services. Throughout the rest of this article I'll be making reference to the WebServiceClasses component and not the WebServiceConnector component. The WebServiceClasses component is the minimum set of classes necessary to handle SOAP transactions programmatically, while the WebServiceConnector is more of a visual aid for accessing Web services from Flash. I believe in using a programmatic approach because it gives developers more control over their applications, allows them to better understand how the API works, and helps reduce file size.
I'm currently working for a company named SensorLogic and we're in the process of rewriting our Web portal to utilize Flash and Web services. SensorLogic is a machine-to-machine (M2M) ASP, and it's imperative that the user experience be as quick and reliable as possible. With the ASP model in mind, we'd like to expose certain services to our customers and resellers so they can build their own applications around our back-end system. We wanted our system to be flexible enough to serve data to Flash, ColdFusion, .NET, or Java. Web services gave us this flexibility. Figure 1 illustrates a basic communications architecture for Flash with Web services.
Although very extensible and flexible, Web services in Flash do have their limitations and drawbacks. The first and foremost is the overhead that SOAP transactions introduce. XML-based protocols are very descriptive, which means they add to code bloat because of markup tags and headers. With this overhead, data usually takes longer to get to the Flash client and the XML has to be parsed, which slows the process down even more. This is definitely not recommended for large data sets or complex objects. On the other hand, if you're dealing with smaller data sets and simple objects, then Web services may be the perfect fit.
Another issue worth considering is security. Unless you plan on implementing SSL, all data sent over the wire is unencrypted. So if your application contains sensitive data, then enforcing secure transactions is a must. In Flash MX 2004 a new security measure was introduced, known as the crossdomain.xml policy file. This file basically says that a Flash client coming from domain A has authority to access services on domain B. This file resides in the Web root of domain B and is automatically read by the Flash client when any Web services are called.
To further explain this issue, let's say we want to write a Flash component that accesses a weather Web service and displays the temperature for a specified locale. This will be a problem if we're not authorized to access the remote server through the crossdomain file. In most cases it won't even exist on the remote server. In a controlled environment this isn't a problem, however. If we have control of the server that provides the weather Web service, we can add the crossdomain file to grant access to authorized clients. For more information on configuring crossdomain files, visit www.macromedia.com/devnet/mx/flash/articles/fplayer_security_03.html.
With all the hype around the new Web service classes, developers seem to think Macromedia has forgotten about Remoting. This couldn't be further from the truth. The Flash Remoting components for ActionScript 2.0 were recently released - and they're larger than life. Nothing has changed in the underlying architecture of Remoting; the new components are just friendlier to ActionScript 2.0 developers. While Macromedia put a good amount of resources into the new Web service classes, this doesn't eliminate the need for Remoting.
If you've read any of my past ColdFusion Developer's Journal articles, then you probably know how much I rant and rave about Remoting. Yes, I'm a bit biased toward Remoting, but that's because I love CF and how nicely it integrates with Flash. All data that is transmitted between the Flash client and the application is serialized using the Action Message Format (AMF). AMF is a streamlined binary protocol that was modeled after SOAP. Flash Remoting automatically takes care of data type conversion from the server to the client and back again. Figure 2 illustrates a basic communications architecture with Flash Remoting.
Notice how Web services can still be introduced into this architecture. The application server can serve as a proxy between Flash and the Web service. An application server such as ColdFusion would invoke the remote method and return the data to the Flash client using Remoting. Taking this approach circumvents the crossdomain.xml security restriction.
As mentioned earlier, if you're dealing with large data sets and complex objects, then Flash Remoting is definitely worth a look. In most cases your performance will be better. If you're doing simple transactions such as retrieving stock quotes and weather data, then performance will be about the same or the difference will be too negligible to even notice.
One of the major drawbacks of Flash Remoting is the cost. The license runs $999 for a single-CPU license at the time of this writing. This is not an issue for CFMX developers (or Java/JSP developers using JRun 4) because Flash Remoting comes built in! If you are building enterprise applications with Flash but you're not on a CFMX server, then purchasing a Remoting license is a no-brainer. I can say from experience that it's worth every single penny for the performance you'll be gaining. Okay, enough talk; let's take a quick look at the application.
The File-Browsing Application
Although I've spent a good amount of your time talking about each technology, I'd like to walk you through a basic file-browsing application. If you'd like to download the source code for this application, please feel free to do so at www.sys-con.com/coldfusion/sourcec.cfm. View the README file to see how to configure the application. The application consists of a Tree component that allows you to select a folder and display its contents in a DataGrid component. Each time a tree node is clicked, a service call is made to the server for data. The ComboBox controls whether the service call is made using Web services or Flash Remoting. Figure 3 shows a screenshot of the application at work.
Web service and Flash Remoting objects are created with ActionScript in a similar manner. After the objects are created, a service method called getFiles is invoked. This method resides in a CFC called fileBrowser.cfc, which can be invoked through a Web service call and also through Flash Remoting. I want to take a quick second to say how truly amazing CF is. In less than 15 lines of code I can expose both a Web service and Flash Remoting method that can be consumed by a Flash client. If you've had experience exposing remote methods with any other technology, then you can truly appreciate how simple CF makes this.
After playing around with the application there are a couple of things that you'll most likely notice. Overall, the performance of Flash Remoting will be better than that of Web services. When retrieving a small number of data sets the difference will be negligible and not even worth noting. That's why the "Get All Records" button was added, because I think this truly demonstrates what I discussed earlier. Since we're dealing with what could be considered fairly complex objects (recordsets) and large amounts of data, you'll see that Flash Remoting truly outperforms Web services. While testing on my local machine it generally took the Web service classes 4-5 seconds to retrieve and display 783 records, while it took Flash Remoting less than a second. Play around with it and your results may vary!
In this article I touched the surface of Web services and Flash Remoting with a few pros and cons of each. There's definitely enough information on these two topics that an entire book could be devoted to them. I encourage you to download the sample application and test it, tweak it, and break it. I hope it will ultimately help give you enough information to decide which technology fits your needs, maybe one or the other, maybe both.
One area that I did not have a chance to touch upon is debugging. If you're interested in learning more, I recommend you take a look at the Log class for Web services and the NetConnection Debugger for Flash Remoting. If you'd like to learn more about the NetConnection Debugger, please check out my earlier article in CFDJ, Volume 4, issue 10. All in all, the future is bright for Flash and ColdFusion developers. Stay tuned!
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works