Flash Article

Macromedia Flash MX Professional 2004 empowers a new breed of applications that fuses the rich-client capabilities of Macromedia Flash with server-side technologies—including, but not limited, to J2EE, .NET, and ColdFusion. These Rich Internet Applications allow you to deploy intuitive and interactive user interfaces either upon an existing server-side infrastructure or upon middleware solutions designed expressly for Rich Internet Applications.

In this article I consider some possible solutions for integrating client-side with server-side code. I also consider the technologies behind XML connections, web service connections, and Flash Remoting connections. After appreciating the relative benefits of each technology, you'll understand how to select the technology that is most appropriate to your own needs and capabilities.

Evolution of Integration Technologies

Macromedia Flash has evolved rapidly in the last few releases from a tool for animators to a tool capable of providing a rich-client interface for Internet applications.

In earlier versions of Flash, integrating a dynamic Flash interface with server-side technology required ingenious solutions comparable to the use of CGI scripting in the early days of web applications. Using the LoadVars() method call allowed the posting of HTTP form data from client to server, and capturing of an HTTP response.

Flash 5 improved upon this simple integration by providing client-side support for XML, along with a lightweight programming interface for creating and parsing XML documents. Flash MX improved the performance—in some cases as much as 400 percent. In order to keep Macromedia Flash Player lightweight, its XML capabilities were kept to a minimum: There was no support for schema validation, no support for namespaces, and only a simple parser that encouraged a regular document structure. However, this didn't stop applications from passing data as XML documents between clients and servers.

Towards the end of 2001, Macromedia unveiled Flash Remoting, a technology aimed at empowering developers with the capability of building a new breed of rich-client applications where the best of the desktop could meet the best of the web. Developers could deliver these Rich Internet Applications (RIAs) by adding Flash Remoting to an application architecture and adopting a three-tier development model (see Figure 1) that cleanly separated the presentation tier (Flash client) from the business tier (server-side middleware) and from the integration tier (database, message queues, legacy systems, reservation systems, and so on). Flash Remoting enabled enterprise software systems to deliver more interactive, intuitive, and engaging user experiences than previous web application technologies allowed.

Figure 1. Example of a three-tier architecture showing the presentation, business, and integration tiers

Note: For more information, read the sidebar about some of the RIAs we at iteration::two have built for our clients.

Flash Remoting continues to provide a fast and powerful means of integrating a rich-client Flash interface with complex middleware built in J2EE, .NET, or ColdFusion.

With the launch of Flash MX Professional 2004, Macromedia is focusing on extending the available technologies for server-side integration with web service support. Though web services were already supported in Flash Remoting, the addition of web services to Flash MX Professional 2004 makes it easier and faster for a Flash client to integrate with business logic exposed as a web service on the server side. Unfortunately, the release of this functionality caused a great deal of confusion within the development community regarding the roadmap for Rich Internet Application technologies.

First off, many people took Macromedia's emphasis on web services as a herald of Flash Remoting's early demise. Though this was never intended to be the case, Macromedia's decision to roll out connectors for web services and XML in Flash—and not provide a connector for Flash Remoting, which is still a stand-alone product separate from Flash—was seen by many as an indication that web services were the new kid on the block.

However, Macromedia did release updated components for Flash Remoting that work with MX 2004 and Flash Player 7. Using these updated components, Flash Remoting will work with MX 2004 and Flash Player 7, and you can migrate projects to the new tools. These components are ActionScript components, not ActionScript 2.0, and there still isn't a Remoting connector component to go along with the WebServiceConnector and XMLConnector components. So, Macromedia has some work to do in the future to build out Remoting support to bring it to the level of support they're providing for web services and XML. However, the good news is that Macromedia has said they are working on such a project, though they haven't provided a specific release date.

You can now choose from a variety of options—including XML integration, web services, and Flash Remoting—when developing Rich Internet Applications. By considering the technical and business motives and consequences behind a particular technology, you can select one that's best suited to your problem domain, business domain, technology infrastructure, and even your own abilities.

Service-Oriented Architecture

Irrespective of which data source technology you choose to adopt for your solution, exposing your application to a set of loosely coupled business services for the purpose of providing a business solution is fast becoming known as a adopting a "service-oriented architecture" (SOA).

With a SOA, not only are business services loosely coupled but they are typically technology-neutral. This means that a number of different client technologies can access them, such as traditional web applications, rich-client Flash applications, mobile applications, and emerging technologies like interactive digital television.

Whether the invocation of services is performed from the client using XML connections, web services, or Flash Remoting, the architecture on the server side need only ensure that its services are available to the appropriate technology.

XML Connections

The simplest of applications might pass a single piece of data from a server—the temperature or a stock ticker's value, for instance. While this is a good example of data integration in action, it's not typical of the data integration capabilities that Flash MX Professional 2004 can solve. More typical are objects—collections of related attributes such as name, age, date of birth, address, credit card details, and the like—or indeed whole lists of objects, such as contacts in an address book, that are passed between a rich client and server.

From a technical perspective, perhaps the simplest solution is the ability to pass data between a client and server using XML. This method describes data as a textual document and uses an XML schema to define the contract between client and server as to how data is exchanged. On both the client side and the server side, data needs to be serialized and deserialized from an XML document into one or more related objects.

In Flash MX Professional 2004, the XML connector allows a Flash client to send and receive data over HTTP. On the client side, you can parse data in an XML document passed from the server using the XML parsing capabilities of Flash Player, or you can use XPath expressions to select values quickly using absolute and relative paths.

XPath notation is an extremely powerful way to select objects from a dataset using wildcards and predicates. For instance, the notation /Customer[@telephone="+44131*"] selects all customer objects whose telephone number begins with "+44131" (those located in Edinburgh, Scotland).

In a service-oriented architecture where an XML-over-HTTP API exists, XML connectivity in Flash MX Professional 2004 offers a simple and powerful integration solution with little or no server-side changes required.

However, parsing XML on the client is an expensive operation that can impact performance as your application scales. Furthermore, in the same way that you typically architect an enterprise solution to hide the implementation of your model, binding your client to an XML schema can lead to a brittle application architecture that's not flexible enough to accommodate evolving or changing XML schema. In my experience at iteration::two, working with significant XML protocols for loan scoring, credit scoring, and insurance application—as well as XML schemas in industries such as e-learning and publishing—I find that XML schemas are typically evolutionary in nature and, for scalable applications, should be decoupled from the presentation tier.

XML connectivity should be a technical consideration if your service-oriented architecture already exposes your business tier through an XML interface, if you have control over the stability of the schema, and if squeezing performance out of the player when passing large datasets is not a huge concern.

Web Services

Web services bring a standards-based solution to client-server integration. Where they expand upon the XML connection is in remote procedure calling (RPC). RPC takes the service-oriented architecture a step further by allowing you to name remote services, invoke business methods (a more object-oriented term for procedures) on those remote services, pass data to these remote methods as arguments, and receive the results of that method call back to your client application at a later time. Simple Object Access Protocol (SOAP) is a web service protocol that, like XML connections, Macromedia Flash MX Professional 2004 supports out of the box. Support for web services is provided through ActionScript classes. Therefore, large sets of data that are passed through a web service cannot be processed as quickly as other technologies that are directly supported within Flash Player, such as Flash Remoting.

By exposing business logic on a server as a web service, a Flash client can invoke that business logic remotely, passing arguments and receiving results for display on the client interface. Exposing business logic as a web service can be a relatively painless task with most server-side technologies; ColdFusion MX allows "remote" declaration of components, which transparently publishes them as web services. This behavior is built upon the Apache Axis technology for Java, so Java middleware can similarly be exposed as a web service. Likewise, .NET advertises significant support for web services and makes it possible for you to expose server-side business logic in this manner.

One misconception prevalent in the development community suggested that the security sandbox of Flash Player was too restrictive, rendering web service integration useful only within the Flash authoring environment or only for connecting to your own web service. Let's address this issue by first describing it.

There are no sandbox restrictions in the Flash authoring environment. This allows Flash clients to consume web services (that is, invoke methods on remote web services) that exist outside the network domain of the Flash movie. Sample applications abound that demonstrate connectivity to the many public web services available at sites such as XMethods, or that use the Amazon or Google web service APIs. However, as soon as these Flash clients are published and deployed on a web server, the Flash sandbox—quite rightly so—prevents those clients from exchanging data with the foreign web service. Instead, to communicate with this web service, you must provide a web service proxy (see Figure 2).

Figure 2. Using a web service proxy to integrate with third-party web services

Residing on the same server from which the Flash client is served, a web service proxy is a local (to the client) service that the Flash sandbox permits to integrate with web services. The job of the local proxy is to receive requests from the Flash client and pass these requests on to the remote service. Since these requests are passed on (or "proxied") from within the server, the Flash sandbox no longer applies. Within the development community, there was much confusion as to why this should be the case. For simple demonstration applications such as a Google search, an Amazon catalogue query, or a public web service call to fetch weather information or stock quotes, having to provide a proxy seems like overkill. However, when you generate a production application, it's foolish to entrust the client-server communication of your application to an API that is not under your own control and that is likely to change at any time.

In a three-tier architecture, you might consider the Flash client to be the presentation tier, your proxy to be the business tier, and a third-party web service to be the integration tier. With a proxy sitting in the business tier, however, adapting the third-party web service for your own presentation tier insulates your presentation tier from any integration issues. If the public API of the web service changes, you need to make only a single server-side change, rather than changes in one or more Flash clients.

An additional benefit of the web service connectivity model is its support for SOAP faults. In web services, faults are the means by which a failed attempt to invoke a remote method does not result in a program error but, instead, returns an error to the client, allowing graceful handling of remote error conditions. In this way, if the remote service is unavailable for any reason, the user experience need not be compromised.

As a standards-based approach to remote procedure calling, the web services initiative defines standards for securing web services and controlling access to web services according to role-based permissions. This yields an important gain over simple XML connectivity beyond the SOAP protocol. Web services are also gaining favor because an increasing number of popular servers support exposure of logic using SOAP.

However, web services also serialize and deserialize data across the wire as textual XML, which requires parsing and construction of XML documents on the client. As an application scales in complexity and the number of objects and volumes of data being passed over the wire increases, web service performance will reach a plateau. Because it is a best practice to consume third-party web services on the server rather than the client—and the Flash sandbox enforces this—the use of the web service integration features of Flash MX Professional 2004 is likely to be confined to applications where developers are willing to maintain a consistent API on the server and do not expect to pass large datasets across the wire as a typical use case.

Where scalability and performance become architectural concerns, or where there is no desire on the part of developers or architects to add a web-service tier to their server-side architecture, consider Flash Remoting as a viable candidate.

Flash Remoting

As a stand-alone commercial product, Flash Remoting offers a tightly coupled way for Flash clients to invoke or call methods on native server-side objects that are deployed within J2EE, .NET, or ColdFusion servers. Flash Remoting uses a binary protocol, serialized and deserialized data, and encoded remote procedure calls using a binary message format called Action Media Format (AMF). AMF is delivered over HTTP or HTTPS, meaning that, like XML and web service connectivity, a Flash client can integrate with a server-side application over HTTP and secure HTTP, requiring no additional firewall configuration to conventional web page technologies. Support for Flash Remoting is integrated directly into Flash Player, providing the fastest means possible for retrieving data into your application.

Though many are reticent to adopt proprietary technologies, it's worth noting that there are already commercial and open-source alternatives to Macromedia Flash Remoting MX that use the AMF protocol to provide similar functionality for languages, including Java, PHP, and even Perl. Like the Flash SWF movie format, the proprietary nature of the technology does not carry concerns of technology lock-in when open-source alternatives exist.

Those who utilize Flash Remoting MX do so for its tight integration with the development environment as well as for the Macromedia support. When development teams are responsible for end-to-end delivery of a product—designing and developing the presentation tier, business tier, and integration tier in concert—the tight-coupling of Flash Remoting is an attractive technology proposition, allowing for a clean separation of the model, view, and control.

As a binary protocol, Flash Remoting performs better than most data integration technologies because data is passed over the wire in a compact manner. Developers don't need to get involved in data serialization and deserialization because Flash Remoting transparently maps objects from the client-side ActionScript technology to the server-side technology, whether it's J2EE, ColdFusion, or .NET. Within the development community, and particularly in the J2EE community where Flash Remoting solutions are currently more likely to exist in large enterprise systems, open-source tools ensure the transparent mapping of value objects and collections of value objects between Flash and Java, using JavaBean-style introspection. For instance, the ASTranslator Project, resulting from the collaboration of CarbonFive and iteration::two developers, makes it straightforward to provide a Flash client on top of a service-oriented J2EE architecture. Additional open-source projects, including the FlashGateKeeper Project from CarbonFive, extend the role-based and permission-based security of the J2EE technology stack into a Flash Remoting solution, giving much finer granularity over security than can be achieved in a Rich Internet Application.

The combination of increased performance; the ability to invoke methods on middleware business objects deployed in their native form into an enterprise application server; and the proliferation of surrounding technologies that provide a transparent object mapping between client and server with fine-grained control over application server security make Flash Remoting a strong technology candidate for enterprise-grade applications where scalability, performance, and security are key drivers.

Data Binding

For each of the three technologies I have discussed (XML connections, web services, and Flash Remoting), the data-binding capabilities of Flash MX Professional 2004 allow you to assign arguments for remote method invocations (and their results) to visual components, pull data from components such as text entry fields, and populate user interface components such as data grids and list boxes.

As well as specifying these bindings visually, you can configure them declaratively using the underlying ActionScript classes. It's beyond the scope of this article to advocate which best practices enable collaborative development on enterprise-level RIAs. Suffice it to say that you should consider manual data binding using the ActionScript 2.0 libraries for large product teams.

Explore the View Helper design pattern as a means of encapsulating nonvisual data binding.

Insulating Technology Choice through Architecture

Now that you've learned about the technology and business requirements that might lead you to consider one integration technology over another, as well as consider the skills and capabilities of the development team, you should realize that the appropriate technical architecture on the client side of a Rich Internet Application can minimize the impact of changing that decision in the future.

You are urged to explore the Business Delegate and Service Locator patterns, both of which can encapsulate the location of remote services, the invocation of remote procedures, and the handling of the arguments and results to these remote procedure calls to the rest of a client application.

Developing a Rich Internet Application can proceed visually, using onscreen components to configure data sources and bindings of data to user-interface elements. In many instances, visually deploying a connector and setting up bindings within the Flash authoring environment is likely to be the simplest and most acceptable solution. However, as the complexity of the application scales and the number of remote method invocations match the increase in the possible use cases for Rich Internet Applications, fleshing out an application architecture on the client using these design patterns can introduce a thin layer of architecture that mediates between the presentation tier, or view, and the business tier on the server. With this architecture in place, you can adopt a hybrid scheme of integration technologies or swap different integration schemes in and out of the application architecture as business or technical requirements demand, with little or no additional impact on either the user interface or the server-side implementation.

As is often the case, your decision whether to introduce this architecture should be driven by your business requirements but you'll do well to consider this as a means of refactoring your data integration as the project evolves.

Integrating Flash clients with server-side technologies empowers us to deliver Rich Internet Application experiences. By making an informed decision about which data integration technology to use, we can be sure that we deliver these interactive and memorable experiences in a simple, easy, and effective manner.

References

"Reality J2EE: Architecting for Macromedia Flash MX" by Steven Webster (Macromedia Press).
In this book a great deal of attention is given to Flash Remoting, with particular emphasis on remoting to an Enterprise Java application on the server. Additionally, my book covers client-side architectures that are necessary to encapsulate the Flash Remoting technology and separate the presentation and business tiers on the client. This is relevant not only to J2EE integrations but also to ColdFusion and .NET.

"Macromedia Flash MX 2004 ActionScript 2.0 Dictionary" by Flash Experts (Macromedia Press)
Alistair McLeod of iteration::two and I contributed the chapter "ActionScript 2.0 Design Patterns for Rich Internet Applications," in which a client-side architecture is presented including the Business Delegate, Service Locator, and View Helper design patterns, which allow the development of an architecture that's agnostic about the integration technology used: XML, web services, or Flash Remoting.

"Data Binding in Flash MX Professional 2004" by Aral Balkan (Dev Center)
Aral Balkan's article describes the data binding technology you can use to bind data returned from each of the data sources discussed in this article to visual and nonvisual user-interface components.

---

About the author

Steven Webster is Technical Director at iteration::two, a Scottish software consultancy focused on delivering Rich Internet Applications using agile development methods. A Computer Science and Electronic Engineering graduate of the University of Edinburgh, Steven worked as a mixed-signal design engineer, performing digital and analog circuit design for a semiconductor house before embarking on a software engineering career. As a founder of iteration::two, Steven is recognized as a software engineer with a strong understanding of J2EE design, architecture, and development methodologies who works at the forefront of mobile application development and rich-client development using MacroMedia Flash MX and J2EE.

Recognized within the developer community as an authority on Rich Internet Application development using Flash and J2EE, Steven is the author of Reality J2EE: Architecting for Flash MX (Macromedia Press, 2003) and "ActionScript 2.0 Design Patterns for Rich Internet Applications" in ActionScript 2.0 Dictionary (Macromedia Press, 2003). He is a regular contributor to the "Engineering RIAs" column at Flashmagazine.com. Through iteration::two, Steven works closely with Macromedia on new tools and technologies for Rich Internet Application development.