Flash

If you do Flash Remoting in .NET - read on. We at MXDJ began to hear about FlashORB and went straight to the source for an inside view of this alternative to Macromedia's Flash Remoting.

Everyone is talking about rich Internet applications. Some are experimenting; others are building real applications. Flash MX downloads are exceeding all expectations, and there is a general consensus that the Internet has evolved enough to take the user experience to the next level. With all the advancements on the client side, however, there has not been enough innovation on the server side. Macromedia has provided the initial set of the server-side technologies with Flash Remoting, but has not updated them since the initial release. The technology is still intrusive, noncohesive, and expensive. Many of these factors have influenced the creation of several alternatives to Flash Remoting. One of them, FlashORB, is reviewed in this article.

FlashORB is essentially a Flash Messaging server, consisting of three major subsystems: Flash Remoting, Web Services Gateway, and XML Socket Server. Available in two editions (Java and .NET), the software provides a new way to integrate Flash clients with the server-side components (Java/.NET objects, EJBs, Web services, business applications). Architecturally the product is positioned between the client Flash UI and the server-side application; as a result, FlashORB addresses the needs of both UI and server component developers. For example, facilities within FlashORB like Call Tracing in the Management Console and the ActionScript code generator aid the UI team, while custom serializers, activation modes, and object factories help server-side developers. FlashORB nicely separates the responsibilities of the UI and the sever-side development teams.

A Few Words About Flash Remoting
If you are new to the concept of Flash Remoting, it is worthwhile to get a brief overview of the technology before delving into the core of FlashORB. The primary purpose of Flash Remoting is to enable Flash clients to perform invocations on server-side services (Java/.NET objects, Web services, etc.). The technology consists of two primary parts: Flash Remoting Components and Flash Remoting Server. The Remoting components are a set of ActionScript programs that enable connectivity and messaging between Flash clients and the server side. The Flash Remoting Server is responsible for receiving client requests, dispatching invocations on the specified components, and serializing responses in the appropriate format. The format utilized in Flash Remoting is called AMF (Action Message Format); it is a binary format but is streamed over HTTP/HTTPS to ease firewall traversal. Code I and Code II demonstrate the server-side class and the client-side ActionScript invoking a method of the class.

The operation flow is very simple.

1. Flash client creates a connection to a server running at "http://remoting server url" (line 3).
2. It obtains a reference to a service identified by the full type (class) name. (line 4).
3. The client invokes a method from the server class, as if it is present locally (line 5).
4. Flash Remoting Server receives client request and performs method invocation on the designated type(class). The result from the method invocation is sent to the client.
5. The response received from the server is dispatched into a function named as methodname_Result, where methodname is the invoked method (line 7).

Better Flash Remoting with .NET
Now let's take a look at FlashORB as a remoting solution focusing on the main features differentiating it from the competing alternatives available in the marketplace. Each feature will be demonstrated with an example to clarify its use with actual code. For the simplicity and clarity, all of the examples use FlashORB.NET - the edition of the product for the Microsoft.NET environment; all the features discussed are also available in the Java edition.

Type Adaptation
One of the major product differentiators is the type adaptation system. Driven by the design principle of nonintrusive integration, the type adaptation system allows automatic plug-and-play of FlashORB into user applications. To understand how type adaptation works consider the example in Code III and Code IV.

The Flash side sends an untyped object to the server (line 10). When FlashORB receives such an object it tries to convert it into the formal argument type of the invoked method. All the fields from the untyped object are matched against the fields in the formal argument type. This process of converting data received from Flash clients into formal argument types is called "type adaptation." Although the example shown is rather primitive, FlashORB can easily convert even the most complicated data structures. It also works well with the built-in collection and utility classes. For example, an instance of ActionScript Array can be adapted to System.Collections.ArrayList or System.Collections.Stack or any other data structure where data is organized in a linear fashion.

Security
The lack of any security is the Achilles heel of most Flash Remoting servers. A particularly egregious example in Code V demonstrates the severity of this omission. Since all public classes and their corresponding public methods are automatically exposed for Flash Remoting invocations, the code can shut down any Java VM or IIS application.

As you can see in Code V, without security restrictions in place it takes just a few lines of code to bring down the entire server. Therefore, securing Flash Remoting applications is of critical importance. Using FlashORB's configuration file or the management console, developers or administrators can restrict or grant access to the code identified by the package/namespace name or full class name. There are four types of restrictions that can be grouped together: restriction by role name, IP address, subnet address, or hostname. For example, to prevent the code above from working, FlashORB can be configured to reject access to java.lang.* for any requests arriving from clients whose IP addresses match the *.*.*.* pattern.

Remote References
The concept of remote references is not new in distributed computing. However, it is a novel in the area of Flash Remoting. FlashORB is the only server supporting remote references. If you're wondering what they are and how it works consider the example in Code VI.

Remote references are client-side proxies to server-side objects. On the server side a remote reference is created by developing a class that implements the Flashorb.IRemote (line 3) interface and providing a method that returns an instance of itself (line 9). The ActionScript code shown in Code VII demonstrates how to obtain a remote reference to an instance of the RemoteReferenceClass class and invoke its methods.

A Flash Remoting service invokes a method on a server-side object (line 5). Since the method on the server side returns an instance of Flashorb.IRemote, FlashORB serializes it as a remote reference. The client side receives and caches the reference (lines 7-9) and then performs a remote method invocation via the remote reference object (line 11).

This feature brings the UI and the server sides closer together and provides an extra level of sophistication for the client/server applications.

Management Console
The FlashORB management console is a Flash Remoting application designed to simplify the tasks of managing and configuring the product. Currently the console provides the following capabilities: display and/or configuration of the product runtime information, FlashORB security, logging categories, logging policies, handler chains, and object factories. Also, the console exposes the Call Trace feature described in greater detail later in the article. Image I is a screenshot of one of the modules in the management console.

XML Socket Server
FlashORB was designed to provide a rich framework for building interactive rich Internet applications. The requirements of the rich-client applications go far beyond Flash Remoting and demand support for various message exchange paradigms: point-to-point, broadcast, unicast, server event push, etc. FlashORB includes an XML Socket Server to address these needs. The socket server is very lightweight and is optimized for the maximum performance. As the name suggests, the primary usage of this feature is processing XML documents; it can, however, also process binary messages. It has a rich set of easy-to-use APIs to facilitate building interactive messaging applications with the features like chat, message broadcast, event notification, and asynchronous server-side updates. For example, FlashORB Management console uses XML Socket Server to receive a continuous stream of server "runtime stats" without resorting to a sluggish polling architecture.

Call Tracing
Call tracing is a concept slightly similar to what Flash developers know as the "NetConnection Debugger." If you are not familiar with this concept, NetDebug is a debugging facility that exposes detailed information about Flash Remoting calls. The biggest disadvantage of this, however, is that NetDebug works only in the development environment for calls that occur during the current execution of the application. It is impossible to inspect Remoting calls from previous application runs. Unlike its Macromedia counterpart, FlashORB call tracing is a server-side feature. As a result, it works regardless of whether the Remoting application was executed in a development environment, a standalone Flash player or in a browser. When the feature is enabled, the server efficiently persists the data about Flash Remoting calls. This allows the Call Trace subsystem to provide data about the invocations that occurred during the current session, or any previous session. Additionally a facility is provided to apply search filters onto the data in order to highlight specific invocations. For example, you can create a filter to search for all invocations where invocation time is greater than 500ms and method name contains verb "set."

The FlashORB management console provides a graphical Call Tracing module to make this information easily accessible to developers. The module allows observing invocations in real time as well as browsing and searching the call trace store. Each invocation displayed in the module can be inspected to get the details about method argument values and the return value. Image II is a screenshot showing the Call Tracing module from the console.

Conclusion
As application developers seek new ways to differentiate their software and to improve the end-user experience, the client/server development frameworks must be able to provide a new, rich set of features. Flash Remoting is a great client/server integration approach, but it must rapidly evolve to simplify the integration and shorten the gap between UI front ends and server-side components. FlashORB is an example of a quickly evolving, feature-rich development framework. A free evaluation copy is available at www.flashorb.com; try it out!