A Flash-forward look

MACROMEDIA’S MX product line, unveiled last week, charts a future for Internet applications that beckons two very different groups of developers. Flash MX on the client side and ColdFusion MX on the server side converge on the formula that made Visual Basic successful: powerful components and easy-to-use tools for assembling them.

With its new componentized UI widgets, Flash MX aims for the universal client capability that Java and DHTML (dynamic HTML) never achieved.

“Until this version, GUI programming in Flash was weird,” says Colin Moock, author of O’Reilly’s ActionScript: The Definitive Guide.

Now the Holy Grail — interfaces that work like applications, rather than sequences of context-free Web pages — seems within reach, he says.

Bruce Meikle, production manager at Toronto-based G+A Electramedia, agrees. His company already uses Flash to enable customers such as Mercedes-Benz Canada to feed streams of XML data into customized containers on Web pages. Now these containers are becoming interactive. “Upgrading users to Flash 6 is painless,” he says.

After the run time is installed, it can deliver an experience that, for the first time, works in standard, predictable ways across platforms and browsers. Thanks to a new persistent data store called SharedObject, Flash also becomes an option for disconnected clients. A widget embedded in a Flash-based Web application can be reused on an iPaq for data collection in the field.

ColdFusion MX, which remakes the venerable application server in Java, appeals to longtime ColdFusion developers who want to deploy into J2EE (Java 2 Enterprise Edition) environments, as well as to J2EE shops where ColdFusion’s simple tag-based programming model will be a godsend. ColdFusion MX includes Macromedia’s JRun application server, but the company will also jointly market and support the product for IBM’s WebSphere and Sun’s iPlanet. Java classes and EJBs (Enterprise Java Beans) in these environments are exposed to the scripting engine as ColdFusion components. (In the .Net environment, native .Net components are handled in the same way.)

Conversely, native or acquired ColdFusion components can be wrapped as Web services using a simple declarative syntax. Most Web developers lack the skills to wrestle with middleware componentry.

“How many people have deep EJB (Enterprise Java Beans) experience?” asks Neil Giarratana, Web development director at IniNet in Keene, N.H. He has long valued ColdFusion’s ability to solve 80 percent of typical problems while requiring 20 percent of the specialized skills. Applying the 80/20 rule to the J2EE realm looks like a huge win.

Each of the two halves of the MX line delivers independent value. Although the two need not be joined at the hip, Macromedia, of course, prefers that arrangement. The deal sweetener, an architecture called Flash Remoting, is a carefully chosen mix of open and proprietary protocols. Through a gateway that’s included in ColdFusion MX, and will also be made available separately, Flash clients can use remote components. These include native ColdFusion services, which deliver the highest levels of abstraction (that is, data-bound controls), and also generic Web services. In both cases, the gateway handles basic plumbing such as proxy generation and data marshalling.

In both cases, the gateway handles basic plumbing such as proxy generation and data marshalling. It also wraps the client/server conversation in a session context, and maps application-server conventions for role-based security onto a common credentialing API.

Server-side connectivity to Web services is standard. It’s based on the Apache Axis SOAP (Standard Object Access Protocol) engine, to which Macromedia is a contributor. But client-side connectivity to Web services depends on a proprietary protocol spoken between the Flash client and the gateway. Although Flash is XML-capable, it isn’t put forward as a direct consumer of Web services.

Macromedia cites several reasons for this restriction. One is the laudable intent not to bloat the player, and thus retain the small footprint that has allowed it to become ubiquitous. Another is a Java-like security sandbox that allows code in an .swf file access only to resources on its server of origin. Yet another is performance. The AMF (Action Message Format) protocol, which passes around binary-encoded ECMAScript objects, is far terser than ASCII XML.

To these sensible explanations we must also add Macromedia’s need to create a dependence on its middleware. The Flash player is on 415 million of 500 million Internet desktops, according to Macromedia. Version 6, rolling out at the rate of 3 million per day, will be pervasive long before Microsoft’s CLR (Common Language Runtime) becomes a factor on the desktop. The Flash run time is already positioned as a universal Internet client that can connect to distributed Web services — a core benefit that the CLR may not achieve for years.

Given the sweeping ambition of Macromedia’s plan, it’s useful to recall that the company’s roots, on both sides of the house, are firmly planted in application development. Empowering client-and server-side developers with easy-to-use tools and frameworks is a core competency. Creating Internet infrastructure is not. Flash Remoting leans over the line, as does a pending initiative code-named Tincan, which aims to bring two-way data communication and streaming audio/video to Flash developers.

Pushing the envelope is a good thing. Internet standards follow pioneers who deliver code that works and does what people want. Web services that encapsulate business logic aren’t exciting until applications make those services come alive for users. If Macromedia can transform Flash from a multimedia shell into a popular presentation layer for Internet-based business applications, the missing pieces of the Web-services puzzle — identity management; security context; reliable messaging; and real-time, two-way data communication — will come into focus more quickly.

Meanwhile, the creative hackers who helped to push Flash into its new role will continue to find unexpected ways to use it. Gamers have already built communication servers based on the Flash XMLSocket object, and there is a Flash implementation of XML-RPC (remote procedure call). Given a scriptable, network-aware, and XML-capable run time, there’s no telling what capabilities people will discover. The MX agenda, based on proprietary Flash Remoting, invites lots of open experimentation. If Macromedia goes with the flow, it can win the hearts and minds of a generation.