The Executable Internet

As the Internet evolves, the demand for a Web interface that rivals the functionality of desktop applications has become evident. The solution is the "executable Internet," a rich-client technology boasting a client-side browser plug-in capable of making the user's experience of a Web page much more interactive and powerful. The combination of ASP.NET and Macromedia's Flash Remoting is one of the most compelling rich-client interfaces available to overcome today's development limitations.

The Limitations
In order to fully leverage the immense power of the .NET Framework on the Web, an interactive, responsive, and effective desktop-like user interface is required. Limited by the restrictions of HTML and alternative technologies such as DHTML, developers are forced to conform to browser standards when building their user interface and their application's functionality. These limitations cause Web applications to be much less interactive and powerful than their desktop counterparts.

Enter the Rich Client
Rich Internet applications offer many of the same possibilities as desktop applications, with the communication power of a Web browser. Rich-client applications have the ability to immediately react to a user's input and then display, process, or validate data based on that input while the user is either on- or offline.

By executing client-side scripts, rich-client applications also make use of the processing power available on the client computer rather than relying only on the Web-hosting server. This feature allows a much more efficient use of bandwidth and processing power than strictly server-side processing.

Rich Internet applications also make the client/server communications taking place in an application nearly invisible. This is accomplished by using an asynchronous, event-driven callback model instead of the traditional Web model. This asynchronous model can also decrease the amount of Web traffic needed to communicate between client and server, and increase the interactivity of the application by allowing the client to retain control of a Web Form while a call is being made to a remote server object.

About Flash
Macromedia's Flash Player technology is the most widely distributed rich Internet application on the market today. Macromedia Flash Player is currently installed on more than 400 million client devices, including platforms such as Windows, Macintosh, Linux, Sun Solaris, Microsoft TV, Pocket PC, and others. It is estimated that a version of Flash Player is available to over 98% of Web users. Flash is supported on essentially all version 4.0+ browsers, eliminating the client interface compatibility problems encountered with other HTML-based technologies such as DHTML and Cascading Style Sheets. Because Flash is supported in both browsers and devices, Flash applications can be deployed consistently across Internet-connected platforms. Flash Player also has a vast array of multimedia capabilities, including support for motion graphics, video, audio, two-way communications, and complex forms.

Traditionally, Flash's capabilities have been utilized by developers for the familiar "skip intro" animations. With the release of Flash MX, the capabilities of Flash have changed. Flash is now an interactive medium capable of processing complex data-driven business logic as well as rich user interfaces. ActionScript, Flash's scripting language, is a powerful object-oriented scripting language based on the ECMA-262 standard, which is also followed by JavaScript and Microsoft's JScript, making programming in Flash an easy transition for .NET developers.

Flash Remoting .NET
The component essential to the success of rich-client interfaces is the ability to quickly access server-side data. Macromedia's Flash Remoting for .NET provides an interface for communicating between Flash Player and .NET application servers.

Flash Remoting exposes .NET technologies such as Web services, ASP.NET pages, and .NET assemblies as remote services to Flash, allowing them to be called as if they were local ActionScript objects. Flash Remoting MX is used in .NET applications as a custom server control in ASP.NET pages or as a namespace in .NET assemblies, code-behind class files, and Web services. This gives the .NET developer the flexibility to build server-side logic in a variety of formats, all of which are accessible to the client.

Flash Remoting provides transparent conversions between Flash data types and the server-side .NET data types. These conversions take much of the work out of the hands of both the client and server-side developers, allowing focus to reside on the business logic and client interactivity instead of the object communication.

Flash Remoting for .NET communicates between the Flash client and the .NET server using a message format called AMF (Action Message Format), which is delivered over HTTP and modeled on SOAP. AMF is a binary message format, the likes of which have been found to reduce network traffic up to 50% compared to SOAP-formatted communication. Because it is delivered over HTTP, AMF is also securable via HTTPS and is firewall safe.

The Flash Remoting .NET environment consists of two layers: (1) the netservices layer, residing in the client Flash Player (available on all Flash Players version 6.40+); and (2) the remoting gateway, residing on the .NET Web server. The netservices layer is composed of a Flash include file containing all of the ActionScript classes necessary to send and receive communications on the Flash side. The remoting gateway consists of a .NET DLL that acts as controller on the .NET runtime that, among other things, handles the conversion of data types between ActionScript and the .NET Common Language Runtime. When this controller receives a request, the request passes through a series of filters that handle serializing, logging, and security before arriving at a service adapter that handles the appropriate invocation type.

Make It Happen
In order to demonstrate how to use .NET Flash Remoting, as well as introduce some ActionScript, I have created a .NET Remoting application available for download from below. In my example I'll demonstrate how to pass DataTables from an ASP.NET page to a Flash object and bind that data to Flash user controls. In this example, you will see how an event-driven, asynchronous model is used to retrieve data from a Web server while allowing a client to retain control of the Web page.

Setting Up
Download and install the Flash MX authoring environment 30-day trial from www.macromedia.com/software/flash, and the Flash Remoting 30-day trial from www.macromedia.com/software/flashremoting. When installed, Flash Remoting will reside in a directory under c:\inetpub\wwwroot\flashremoting (in a typical IIS install).

Next, create a directory anywhere on your system for the application files. This directory will need to be enabled for Web sharing. In my example, I have shared the folder as netJournalFlash. Create a "bin" directory with write permissions within this directory to function as the local assembly cache. Now we copy a couple of files from the flashremoting directory to the new application directory. Copy the flashremoting/bin directory and the flashgateway.dll file, which is the server-side remoting gateway, to the bin directory of the new application. Also copy the Web.config file to the directory root.

The Web.config file contains one of the essential server-side requirements for Flash Remoting, a reference to the Flash Remoting assembly:

If the server receives a Web request containing AMF, it forwards this request to the Flash remoting assembly.

.NET Programming
The ASP.NET code in this example consists of two pages, productList.aspx and productData.aspx. To access data from an ASP.NET file and pass data to and from Flash files, a Flash Remoting custom server control must be used within the page. First, register the Flash gateway:

<%@ Register TagPrefix="MM" Namespace="FlashGateway"
Assembly="flashgateway" %>

The Flash control is added to the page with the following statement:

<MM:Flash id='myFlash' runat=server/>

The Flash Remoting custom server controls contain three properties used to access variables passed to and from Flash:

- Flash.Params
- Flash.Result
- Flash.DataSource

The Flash.Params property is an array of parameters passed from Flash to the .NET application. The Flash.Result property is used to return data to Flash after the server-side processing has occurred. The Flash.DataSource property is used to bind .NET DataSets to Flash Remoting controls.

Let's take a look at the example files. When productList.aspx is invoked, a connection is made to a local Access database and a DataSet is retrieved consisting of the product ID and name for each product in the database. This DataTable is then bound to the Flash control using the control's DataSource property and DataBind() method.

myFlash.DataSource = myDataSet.Tables[0];
myFlash.DataBind();

ProductData.aspx is very similar to productList.aspx, except that it requires a parameter to be passed to it from the Flash client and returns the detailed listing for that single product. In this file, we first check to make sure that a parameter has been passed through the Flash Control, then make the connection to the datasource. The SQL query is then built, using the passed parameter to determine which product to select further data for:

string sqlQuery="SELECT description, location, price
FROM productData
WHERE pid=" + myFlash.Params[0].ToString();

And the resulting DataTable is bound to the Flash control as shown in productList.aspx, one of the source files.

Time for Some Action(Script)
Now that we've constructed our server-side .NET code, it's time to tackle the front-end Flash. Flash files are constructed on a timeline consisting of a number of layers. In our file, the top layer (as seen in the "Timeline" window) is titled "functions". When the first frame of this layer is selected, the code for this frame appears in the "Actions" panel. This frame is where all of our ActionScript code will reside. More information about programming in Flash can be found at: www.macromedia.com/support/flash. As mentioned earlier, the netservices layer is the client portion of the Flash Remoting model. The netservices layer is initiated in ActionScript with the following call:

NetServices.setDefaultGatewayUrl
("http://localhost/netjournal/gateway.aspx");
gatewayConnnection = NetServices.createGatewayConnection();
defaultService = "netJournalFlash";
flashService =gatewayConnnection.
getService(defaultService,this);

The gateway.aspx file is a blank ASP.NET file used only when developing in the Flash Authoring Environment. In production, the setDefaultGatewayURL is removed, and the gateway is supplied through a parameter in the HTML that embeds the SWF file in the Web page.

Once this connection is made, the remote .NET service methods may be accessed as if they were local Flash ActionScript resources. The service function we will use will reside inside the netJournalFlash application (or whatever you named your app), so we set our default service to netJournalFlash. To make a call to an ASP.NET page containing a remoting object we would like to invoke, a call to the service function is made, with the name of the ASP.NET page being the name of the method being called:

flashService.productList();

This function calls the productList.aspx page and waits for a response. When a response is received, Flash automatically forwards this response to a function with the name of the call followed by "_Result", in this case:

function productList_Result(result)

When the result is successfully received, this data is then bound to the Flash comboBox with the instance name "myCombo" using the Flash DataGlue ActionScript object, also included with Flash Remoting:

DataGlue.bindFormatStrings
(myCombo, result, "#title#", "#pid#");

with the line:

myCombo.setChangeHandler("loadImageData");

The comboBox has been set to execute the loadImageData function when an item has been selected.

In the function loadImageData, we call the productData.aspx page, passing the value of the product we would like to retrieve the data for:

flashService.productData(myCombo.getValue());

When the response is received by the productData.aspx page, it is automatically handled by the productData_result function. In this function, we set the price and description text fields to their respective values, as well as load the image associated with this product with the line:

theImage = "images/"+result.getItemAt(0).location;
loadMovie(theImage, imgHolder);

Line one creates a string variable named "theImage" and sets it to the images directory, followed by the first result's location column. Line two then loads this image into the imgHolder movieClip on the stage, and our Flash is complete!

Conclusion
As the demand for a more and more interactive Web user experience increases, the need for rich-client interfaces has increased exponentially. As you have seen in the example, the combination of .NET objects, Macromedia Flash Remoting, and Macromedia's Flash Player create a powerful rich-client interface capable of producing desktop-like applications in a Web browser interface.

About The Author
Ryan Moore is the lead software architect and a principal of Balance Studios Inc. of Green Bay, WI. Ryan, a .NET programmer and Certified Macromedia Flash Developer, splits his time between Web and desktop application development. interactive@balancestudios.com

Source Code: ~zip file 79.1 KB