ASP.NET has done an exceptional job of evolving the 3 and n-tier web model, in particular the business logic layer. .NET server controls such as DataGrids, DataLists, and Calendar controls provide adequate presentation- tier elements, but their reliance on outdated Web technologies limits their potential. The Macromedia Flash Player, in conjunction with the .NET FlashOrb, provides an engaging presentation layer that can seamlessly interact with the powerful .NET business logic tier.

ASP.NET Presentation Tier
Since the inception of the World Wide Web in 1989, HTML has been the medium of choice for displaying client user interfaces on the Web. We are all familiar with the fact that HTML's layout limitations far supersede its abilities for displaying and positioning the user interface. HTML, by itself, is not an interactive programming language that can respond to a user's input, rather it is a static document. The only methods used to make an HTML interface appear "interactive" are completely refreshing or redrawing the interface after a user interaction, or make use of a client-side technology to manipulate the static HTML document on the user's computer.

HTML is also very limited in its ability to position its elements. Designs, which on paper have no limitations, have to be broken up into positional elements such as table cells for layout purposes, resulting in implementations that are far from the original concept. Although Cascading Style Sheets have helped with this problem, support of CSS still varies widely between browsers and browser versions.

Two of the main benefits of HTML are that it is a standard that all Web browsers can conform to in order to display user interfaces, and it is a lightweight means of doing so. To state the obvious, 100% of browsers support HTML, although each browser's interpretation of HTML varies. As is well known to developers, an HTML page that lays out perfectly on one browser can appear completely differently in another. This variation leads to inconsistencies in Web sites and forces developers to create numerous versions of a single page in order to meet their presentation goals.

Microsoft's built-in presentation-tier server controls such as DataGrids, DataLists, and Calendar controls rely on a combination of HTML and client-side JavaScript to create user interface elements. Although they use advanced techniques to detect and react to browser incompatibilities, they still have the inherent limitations of HTML. The JavaScript used in these controls allows for the limited amount of immediate user response that these controls are capable of (such as the background color change when a date is selected in the calendar control). Because of the varying support for JavaScript within browsers, these controls must contain a complex set of detection and reaction for each browser type, leading to high overhead and countless headaches in new control development.

Flash Presentation Tier
The Macromedia Flash player is a client-side browser plug-in that can be embedded within an HTML page. The Flash player can function as an entire client interface (www.barneys.com/) or can be used for individual page elements such as animated banner ads (http://movies.yahoo.com/) or interactive graphs. Flash elements (.swf files) are typically created in the Macromedia Flash IDE (www.macromedia.com/software/flash/), although the .swf format is an open source format that can be generated by third-party programs. Ming-Sharp (http://sourceforge.net/projects/ming-sharp) is an example of an open source C# library that can be used to create .swf files.

As with any client-side program, a potential limitation of Flash is the fact that the client has to have the Flash player installed on their system in order to view a page or page element containing Flash. This potential limitation is of minimal consequence though, since Flash is the most widely distributed client-side 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, and Pocket PC. It is estimated that a version of Flash Player is available to over 98% of Web users. The Flash Player is also the most widely distributed video player on the market, and the .flv (Flash Video) format is quickly becoming a standard for video encoding and distribution.

Unlike HTML, the Flash player theoretically functions the same on any platform or in any browser. Combine this with the 98% distribution and the Flash Player is arguably a more widely supported, ubiquitous presentation tier than even HTML. Flash also provides a developer with complete control over the layout of the interface. Elements can be positioned precisely on the screen without consideration for table cells, alignments, etc., allowing the original design to be implemented without compromise.

Unlike HTML, the Flash Player interface has the look and feel of desktop applications. The Flash user interface is responsive, dynamic, animated, and auditory. Like that of desktop applications and unlike that of nearly any alternative Web presentation tier, the Flash Player does not require the "page refresh" for navigation. The Flash Player is able to load content, such as page text, images, movies, forms, and so on asynchronously - without ever compromising the user's control of the interface.

It's a Matter of State
If Flash's presentation tier is superior to that of HTML, why have the overwhelming majority of sites been made using HTML-based interfaces instead of Flash? From a purely technical perspective, the answer is presentation to data-tier communication. In the traditional Web model, business logic is executed on a Web server, therefore, the presentation tier is responsible for passing a user's input from the user's interface to the server. In the HTML/ASP.NET Web Forms model, this communication occurs through the use of HTTP form submissions and POST variables. Although this form of communication has become well refined and very successful, it has an overwhelming drawback: the screen refresh. Each time a user attempts to execute a function, such as submitting a credit card application, navigating to a "Contact" page, or doing a search, the user loses control of the interface and the Web browser is required to re-render the interface after the request. Although this is a process that would not be accepted in desktop applications, Web users have become accustomed to this less than ideal interface interaction.

Until recently, Flash provided no answer to this problem. Flash, although a good interface, had no efficient way to communicate with the business logic tier. Flash also did not contain a robust event-driven programming model for developers to use to respond to the client input. With the advent of Flash 7, an object-oriented, event-driven model is available, and with a product called the FlashOrb, presentation-logic communication can take place in ways previously impossible, allowing a developer to maintain all the power of technologies like .NET for business logic, while using the exceptional Flash Player interface in the presentation tier.

FlashOrb
The FlashOrb is a commercially available .NET .dll developed by Midnight Coders. The standard version of the FlashOrb is available for free download at www.flashorb.com. The FlashOrb manages the communication between Flash objects and .NET server side code. Using the FlashOrb, CLR methods and Web services can be invoked directly from Flash objects. The FlashOrb takes care of all data type conversions between Flash and CLR. Using the FlashOrb, you can pass complex data types between Flash and .NET without any additional code. Through some unique features, the FlashOrb also minimizes the instantiation of .NET classes, which leads to more efficient client- and server-side memory usage.

Using Flash and the FlashOrb, calls to server-side .NET methods can be made from the client-side Flash file without any POST back or page refresh. The Flash object makes an asynchronous request to the FlashOrb gateway running on the server, which then executes the specified method or service and sends back the response to Flash. The communication between the client and server is accomplished using a message format called AMF (Action Message Format). AMF is delivered to and from the server 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 FlashOrb is extremely easy to implement into your .NET application. It requires only that you copy the flashorb.dll to the bin directory of your ASP.NET app and make slight modifications to your Web.Config file. The FlashOrb Professional Edition also comes with a server-side management console that performs sophisticated logging and invocation monitoring, as well as many security features.

Implementation
To demonstrate the implementation of the FlashOrb, I have created a .NET Flash application that uses the FlashOrb to pass an array of structs from a .NET class to a Flash file. If you are interested in viewing the source of the Flash (.fla) file, the Flash development environment free trial can be downloaded from www.macromedia.com/software/flash. The Flash Remoting components will also be needed, and can be downloaded from www.macromedia.com/software/flashremoting/downloads/components.

This example will show a possible use for Flash as a presentation layer while maintaining the business logic on the .NET server (although very limited business logic is used in this example!). The essential files included consist of a .aspx page, default.aspx, a Flash source file, navbar.fla, a compiled Flash .swf file, navbar.swf, a C# .NET class, Navigation.cs, and a Web.Config file.

Starting with the Web.Config file, in essence the only line needed to use the FlashOrb is the following addition to the httpHandlers section:

<httpHandlers>
<add verb="*" path="remoting.aspx" type="Flashorb.ORBHttpHandler,
flashorb" />
</httpHandlers>

This sets up the FlashOrb.dll to process all requests sent to the remoting.aspx gateway from Flash to instantiate the .NET methods and take care of the serialization between .NET and Flash.

The FlashOrb section of the Web.Config file can also configure options like code access security and event logging. Access to your .NET classes can be restricted by several factors, such as IP, host, and role name; and even after this, access to specific methods within a class can be restricted. Using event logging, the FlashOrb can track all requests made from Flash to the .NET methods, along with their success or failure. More information on the configuration of the FlashOrb can be found at www.flashorb.com/docs/.

The Navigation.cs file in this example consists of a class Navigaton that contains a method GetNavigation. The GetNavigation method takes no arguments and returns an array of NavButton structs, as defined within the Navigation class. The purpose of this class is to pass a structure for the Flash file to use to create an animated navigational menu as shown in Figure 1.

Each struct contains:

1. The text for the button
2. The URL that the button should open (if it does not have any "child" buttons)
3. Or another array of buttons that are the children of the first navigational level

Flash coding, which is typically foreign to .NET developers, is done in a language called ActionScript. ActionScript is an object-oriented language very similar to that of any language in the CLR. I will not discuss the setup of the Flash file or the ActionScript used to create the Flash file other than that of the FlashOrb code, but if there are further questions feel free to send me an e-mail.

Connecting to the server-side FlashOrb gateway from Flash is simple using the Flash NetServices class

_root.orbConn =
NetServices.createGatewayConnection("http://localhost/dotnetdj/remoting.aspx");

where http://localhost/dotnetdj/ is the local virtual directory for this example. This line creates a connection to the remoting gateway created by FlashOrb, as defined in the Web.Config file. Once a gateway connection has been established, connecting to .NET classes is as easy as the following:

var orbService = _root.orbConn.getService("dotnetdj.Navigation", this);

where dotnetdj.Navigation is the name of the class that we want to connect to, and this is the default responder, which will handle the data returned from .NET. Using this simply means that we will be receiving the result from this movieclip instance in Flash.

In order to call the desired method ("GetNavigation" in this case), we simply use the following statement:

orbService.GetNavigation();

where orbService is the name of our newly created Flash Remoting object, and GetNavigation is the name of the method we created in .NET.

By default, to receive a response from FlashOrb, you simply create a function of the same name as the service, followed by "_Result":

function GetNavigation_Result(result)  {
	// Respond to results here
}

And that's it for Flash to .NET communication using the FlashOrb! When the Flash movie receives the array of structs from FlashOrb, it iterates through them and creates the necessary navigational buttons as instructed by the .NET method.

Conclusion
ASP.NET has provided developers with an efficient, powerful and robust environment for creating the business logic tier of Web applications. Because of its reliance on existing Web technologies, the use of ASP.NET in the presentation tier has many drawbacks. Macromedia Flash, in conjunction with the FlashOrb, provides an intriguing alternative for the presentation tier in .NET Web apps.

• Figure 1