The February episode of The Screening Room explores Flex 2.0, forthcoming from Adobe (formerly Macromedia). The presenter is Christophe Coenraets, and our 20-minute interview and demo focuses mainly on what's new in version 2.0: messaging services, data synchronization, and Flex Builder 2.0, the new Eclipse-based integrated development environment.
The Flex story includes a number of interesting subplots. There's MXML, a declarative layout language, and the relationship (or not) of MXML to Mozilla's XUL, Microsoft's XAML, and other similar-but-different approaches. There's ActionScript 3.0, a dynamic language with optional static typing that could, with the aid of the Eclipse framework, provide a common environment for scripting and conventional enterprise development. There's the new messaging subsystem, which aims to bring pub-sub messaging to the enterprise desktop (a la Kenamea [1, 2]). And there's the new ability to deploy standalone rich Internet applications that communicate autonomously using REST or web services.
It's worth noting a couple of points that aren't spelled out in the screencast. The forthcoming Flash player 8.5 will be needed to run Flex 2.0 applications, in part because it is the engine that supports ActionScript 3.0. Although that language can run server-side as well as client-side, the Flex 2.0 product line does not, itself, provide support for server-side ActionScript. You build Flex 2.0 services in Java. Separately, you can host server-side ActionScript in the Media Server, formerly known as the Flash Communications Server.
The new messaging services are mainly intended to deliver last-mile connectivity from an enterprise messaging backbone, with initial support for Java Message Service (JMS). However it's also possible to use Flex 2.0's enterprise services as a standalone messaging backbone. Either way, messaging is proprietary from client to the Flex server. Could an open source implementation of that proprietary messaging server be created? Adobe/Macromedia won't aid that effort, Christophe told me, but neither will they go out of their way to block it.
There are lots of variables in play here. It'll be interesting to watch this story unfold.
Former URL: http://weblog.infoworld.com/udell/2006/02/28.html#a1397