When I was asked, I jumped at the chance to do a series on Flash data integration for the MXDJ. Here was a wonderful opportunity to share my popular talks, presentations, and demonstrations with a large, interested audience. In this series I have the opportunity to show you how to use Flash MX 2004 Professional's components to rapidly develop data-driven rich Internet applications. At the conclusion of this series we will have constructed a one-page shopping application capable of using data from several back ends.

I've always loved Flash. I preordered a copy of it after seeing a demo at NAB/Multimedia World back in '97. At the time, the multimedia market was going into a "small correction" and Macromedia was in the process of reinventing itself as a Web company.

Macromedia had evolved a complete tool set for multimedia. They had tools for the creation of interactive multimedia, courseware, electronic graphics, audio editing, 3-D, typography, and even video editing. In fact, that is what I had dropped over to the Macromedia booth to see: their new video editing product. One of the staff explained that the technology had been sold and invited me to check out Macromedia's new acquisition: Flash.

Here was a tool that provided rapid visual development of interactive multimedia and Web objects. This theme of rapid visual development began with Macromedia's early products, Authorware and Director, and is a hallmark of the Macromedia products line. Today Flash, Dreamweaver, Breeze, and FlexBuilder all provide developers with rich, powerful IDEs (integrated development environments) to speed and ease development tasks. Developers can choose to leverage the rapid development offered by a graphical user interface or knock out code by hand in an editor that provides automatic code hinting, syntax checking, and extensive online references.

Flash MX 2004 Professional offers the best of both worlds. The data connection components present the developer with easy-to-use text inputs for connection information. Menu-driven data binding then allows for quick and easy connection to a variety of data sources and interface components. These features, accessed through the visual interface of the component inspector panel, make it possible to rapidly develop rich internet applications. Properties and events exposed by the components programmatic interfaces allow developers to integrate their custom programming with the component framework.

Component-based development and Web services were a key part of the Macromedia MX product line. Jeremy Allaire stated that Macromedia's purpose was to " ...empower a wide range of developers to access the power of object-based component development, rich client/server models and Web services without the pain of complex frameworks."

I really like that part about "without the pain of complex frameworks," and that is the focus of this series. In coming months we will explore both rapid visual application development and customizing applications with the easy addition of a little hand coding.

To start the series off, this month we'll take a look at the history of client/server communication and the evolution of the RIA (rich Internet application). We'll also examine each of the data sources supported by Flash MX 2004 Professional's data components; XML, Web services, and Flash Remoting (see Table 1 and Figure 1).

In the early days of the Internet, Web servers acted pretty much just like file servers. They simply served up any pages and images the client requested. They had no way to interactively exchange data from the client with data on the server.

Along came the Common Gateway Interface, or CGI as it is more commonly known. CGI allowed the Web server to hand off data from the client to other processes, often a PERL interpreter. The Gateway then allowed results from those other processes to be passed back to the client. It got the job done, but there were performance and security issues in early implementations.

CGI led to application servers and server-side programming languages. ColdFusion, PHP, JSP, ASP, and ASP.Net are all examples of application servers and server-side programming environments. Application servers are designed to sit between the client and the data and to process programming directives embedded in Web pages. Certain languages are tied to specific servers. In all cases, all programming directives are processed on the server and replaced with standard HTML before being returned to the client.

While this model of server-side programming is very powerful, developers encounter some important limitations in the typical exchange of data between a client and a Web server.

One key issue is the problem of the page refresh and the Web's statelessness. In a typical exchange of data between a Web client and the server, the data is sent to the server as part of a request for a page. This causes the page in the browser to be replaced with the new page and creates a multitude of issues.

Since the Web is stateless and does not keep a persistent connection between the client and the server, how do we identify a specific client? This constant refreshing also raises another question: How do we persist information in the client? As developers we may want to use the client to store user preferences, shopping cart data, monitor progress through a process, hold scores, etc.

Cookies, passing data in URL strings, and other methods that suffer significant limitations are routinely used to solve these issues. A Flash-based RIA provides simpler and more powerful solutions to these problems.

Browsers present their own set of hurdles to both the designer and the developer. Different browsers on different platforms make pages look and behave differently. Tags do not render uniformly across all clients and client-side scripting (JavaScript) suffers from the conflicting approaches taken by different browsers. While Web browsers' compliance with standards has made great advances, issues still remain.

The typical exchange of data between the client and the server also suffers from some key limitations. A typical exchange is limited to passing variable declarations as name value pairs. All of the rich complex data types developers manipulate in memory, queries, arrays, objects, arrays of objects, cannot easily be passed between the client and the server. Passing of complex data typically requires transforming the complex data into a delimited string. This long, awkward piece of text uses specific characters as markers - delimiters - that separate the different pieces of data from each other. This process of serializing the complex data into a long piece of text and deserializing the string back into a complex data type has significant problems with both performance and the lack of standardization to the process.

XML offers a standardized way of describing complex data as strings and facilitates data serializing and deserializing. However, the problems discussed earlier, page refreshing, persisting data and the lack of a uniform delivery target, remain.

Here is where the Flash player comes in. The Flash player is simply the most incredible "thin client" available. It provides artists and programmers with robust playback of interactive animation and gives the client incredible abilities to send and receive audio and video. All of this is available from players that run on desktops and in browsers, and are only a fraction of a megabyte in size. In addition to these rich media capabilities the Flash player also provides a solution to some of the most basic problems in Web application development.

The Flash player deals with the issues of statelessness and persistence of data through two mechanisms. First, the Flash client has a variety of ways it can exchange data with the server while the player continues to run within its host. No new page has to be returned every time we communicate with the server. With a persistent memory space now established in the client, maintaining the identity of a client and persisting data during a client's browsing session becomes a simple and painless task.

Between a client's browsing sessions data can be persisted through the use of Flash's client-side shared objects. These local shared objects, or SOLs, are powerful "super-cookies" that offer unique benefits to the developer. In addition to an SOL's ability to hold far more data than the typical browser cookie, the SOL can also easily store complex data types including combinations of arrays and objects without any need for the developer to manually serialize and deserialize the data.

The Flash player also provides solutions that allow developers to more easily pass complex data between the client and the server. The Flash player has built-in capabilities for sending, receiving, and manipulating XML. This native ability to handle XML also provides for the implementation of SOAP, the Simple Object Access Protocol. SOAP is a flavor of XML used by Web services to exchange both commands (such as method calls) and complex data (such as queries) between the client and the server.

Web services leverage Web protocols to provide a standardized way to communicate with a Web service's programmatic interface. The use of standard Web protocols and the SOAP schema provide Web services with great flexibility. A client on any platform can use a service on any platform. The flexibility provided by this loosely coupled architecture comes at a small cost in performance.

Flash Remoting-enabled servers provide a more efficient, tightly coupled connection to the Flash player. Flash Remoting is similar to Web services in that it has the ability to pass method calls and complex data between the client and the server. However, instead of using XML/SOAP for client server communication a more efficient binary protocol is used, the Action Message Fomat. AMF provides a much faster, leaner, more efficient client server exchange than the text based XML/SOAP protocols.

Both the ColdFusion and JRun servers from Macromedia have built-in support for Flash Remoting. Macromedia also has products to enable Flash Remoting on J2EE and IIS servers. PHP has an open source remoting solution and there are open source solutions for other platforms as well.

The Flash player's rich presentation layer and its support for advanced client server communication make Flash a cornerstone in the development of rich Internet applications.

More than a marketing cliché, RIAs are the natural evolution of the client/server model. They "...combine the functionality of desktop software applications with the broad reach and low-cost deployment of Web applications - resulting in significantly more intuitive, responsive, and effective user experiences."

In other words, RIAs leverage the global reach of the Internet while overcoming some of the basic problems associated with data exchange over the world wide Web. This allows developers to create a user experience that is much more like using a piece of desktop software than the typical Web application.

Let's take a common Web experience and compare what the user interaction is like as a typical Web application and what it is like as an RIA. Let's examine the user experience of shopping.

Shopping using a normal Web application often starts with a search. The search take shoppers to a new page where the results of the search are displayed. The results provide shoppers with some basic information (title, description, price, etc.) that assists them in making a decision (see Figure 2). They can either go to another page to purchase an item or another page to obtain more information about an item. If shoppers choose to purchase an item they are taken to another page that shows their shopping cart. When they choose to check out, shoppers have to work their way through yet another sequence of Web pages as they provide their ordering and shipping information.

Another page, another page, another page... A simple purchase of two or three items may force the user to navigate literally dozens of Web pages.

Now let's examine the same user experience in a rich Internet application. Shoppers begin their search and the search results are displayed right on the same screen with the search interface. As users interact with the search results, product details appear on the same screen. When shoppers purchases something, their shopping cart appears on the same screen that is serving as their catalog. Checkout is equally painless, occurring, again, right on the same single screen shoppers have been interacting with throughout the process. This is clearly a "significantly more intuitive, responsive, and effective user experience."

If you have a Web application where a user must go through many Web pages to complete a process, you may have a candidate for your first RIA. This series of articles will help you make the transition from typical Web application development to RIA development.

The most important thing that I want any reader to come away with is this: all component-based data integration in Flash follows a common development model, regardless of the data source (see sidebar).

Steps in Component-based Data Integration

1. Add a data connector (see Figure 3).
2. Provide connection information.
3. Add UI components.
4. Bind UI components to data and each other.
5. Trigger the data connector.

In the next issue, XML will be our data source of choice. We'll examine how XML provides a standard text-based source of data for Flash applications. We will bring XML into our applications and build a master detail view. All of this will be done with Flash's visual tools; the components, the component inspector and behaviors. We will also see how to hook in a little custom code to the visual framework.

The third article in this series will examine the role of ColdFusion as a data source for Flash. Many other server technologies can serve as data providers including Java, ASP, ASP.Net, and PHP. However these other technologies do not have the simple power of ColdFusion Components (CFCs). CFCs provide for the rapid development of both Web services and Flash Remoting data sources. We'll examine the theory and put it into practice as we create the data source for the next two articles.

Our fourth article will look at Web services. We will examine how the standard communication model allows access to a wide range of data provided by diverse back ends, including Java, ASP, ASP.Net, and PHP. We'll discuss the technology and implement a Web service consumer in Flash.

The fifth article will examine the technology and implementation of Flash Remoting, which is closely tied to the MX product line.

In my sixth article we will leave the visual framework and add a shopping cart to our application. At that point we will have a very cool RIA - a shopping application that runs within one Web page, or from the desktop as an application.

I hope you will join me as we explore the world of component-based rapid application development in Flash MX 2004 Professional.