This article is more than 1 year old

Hands on with Macromedia Flex 2.0

Tim Anderson gives alpha version a spin

The assumption behind Flex is that an unadorned browser is insufficient as a universal client. Microsoft beats this same drum, and promotes .NET smart clients as the means of adding the performance and rich user interface that only a local application can achieve.

To date, Microsoft’s campaign has had only limited success. Sun’s Java is cross-platform, more mature and more widely deployed, but has been most successful as a server technology.

Macromedia’s Flash client has wider penetration than either .NET or Java, but most of its usage is for multimedia applets. This indeed is what Flash was designed for. Macromedia’s goal with Flex is to make the Flash client suitable for Enterprise clients as well. Flash is fully network-aware, has rich user interface capabilities, and supports scripting with ActionScript, so why not use it as a fully-fledged application platform?

There are a few reasons. The Flash player is remarkable for its size, but cannot compete with a full operating system or even the Java platform in terms of a rich API. The Flash ActionScript language, based on the official Javascript standard known blandly as Ecmascript, is slow and underpowered compared to Java, C# or C/C++.

Third, the Flash IDE is aimed squarely at designers rather than developers. When Flash MX was announced in 2002, Macromedia promised that it would be as easy as Visual Basic for developers, but the promise was unfulfilled and the Flash IDE remains awkward and unfriendly for application development.

Flexing muscles

In 2004 Macromedia came up with Flex as another way to exploit the Flash client. The heart of Flex is MXML, an XML language for defining a Flash user interface. This can include embedded ActionScript, or for cleaner maintenance the script can be written in separate files. The MXML and script then gets compiled to a Flash SWF for deployment.

In Flex 2.0, there are two different deployment models. One is called the Enterprise model, and depends on Flex Enterprise Services, a Java application that runs on any of a number of J2EE servers. The MXML and script files are deployed to the server, and compiled to a SWF at runtime. The SWF is cached to avoid repeated compilation. The other model involves pre-compiling the SWF using the Flex compiler and deploying it directly.

This simpler model does not require Enterprise Services, giving Flex a broader appeal. With both types of deployment, the Flash client can communicate with the server using XML web services (SOAP) or plain HTTP, but one of the key benefits of Enterprise Services is that it additionally enables the Action Media Format (AMF) protocol, also known as Flash Remoting. AMF is an efficient binary protocol, proprietary to Macromedia, and makes it easy to call remote Java Beans or Enterprise Java Beans from ActionScript code.

Flex 2.0 breaks down into four pieces. The first is called the Flex Framework 2, which includes the Flex class library, MXML and ActionScript, compiler and debugger. Next there is Flex Builder 2, which is an IDE built on the open source Eclipse tools. This includes a visual form designer, although it is a relatively simple affair. Macromedia bundles Flex Builder and Flex Framework together. Third, there is Flex Enterprise Services 2, which enables remoting of Java objects via AMF. Finally, the Flex Charting Components 2 anticipate a common reason for using a Flash client, which is to visualize business data.

Next page: Long overdue

More about

TIP US OFF

Send us news


Other stories you might like