For the past few quarters I have had my doubts about Adobe being in the RIA -Rich Interface[or Internet] Applications game. Yes, I knew about the Apollo Flash Player plans and followed the Dreamweaver/Ajax/Spry developments. But Open Laszlo has scored some very impressive wins with its Open Source Flash-based framework that can use Flash 7, 8, or 9 dynamically, outputs to DHTML/AJAX or Flash, and now has no less a customer than Wal-Mart using its technology on its website.
Likewise, one would have to be Borat from Kazakhistan not to know of the series of successes that AJAX has achieved in the marketplace. No less a Web Decimator … uhhh Developer than Microsoft has seen fit to reverse 5 years of deliberate neglect and Rush/Rush/Rush!, HardCore Hardcore All Heads on Deck, Reverse your field on IE and undamn the DHTML/AJAX torpedoes we are going to Atlas Power Push ourselves back into the Web development game. And nudge, nudge; wink, wink; know what I mean, Know what I mean – we intend to use our time proven proprietary extensions; monopoly on the desktop plus browser; and refusal to support W3C and other industry standards to redirect and even wreck progress in the AJAX marketplace until all parties see fit to support our 1 Microsoft Way. But seriously, Everi Body and her neighbor is in the AJAX last developers landrush market trying to stake their claim to the Framework that will make RIA and easy Internet applications one and the same reality we all hope and pray.
And not to be outdone, Sun has finally made Java Open Source – and now the patrician gods of Open Source development may deign to consider Java for some possible server apps. Meanwhile the frontline developers will be pushing both Java and the JVM back to where it should be – right-sized to operate just about everywhere. So J2SE and J2ME may see some dynamic variants, that load themselves cleverly based on introspection of a Java EAR/JAR/WAR manifest and only load or cache what is high priority or absolutely necessary. For those in the smart, Java WebStart is only going to be the start of new Java RIA.
So What Does Adobe Do ?
First, lets take a broader look. Microsoft with its Atlas/Visual Studio, Metro, WMP file format, XAML and WPF, and Expression set of apps has put a big bullseye target on every major Adobe product from Dreamweaver/GoLive and Acrobat PDF through Photoshop and Illustrator to Flash and the Flash Player. So Adobe has to think outside of the Microsoft Box. And to their credit, both Adobe and previously Macromedia have had Mac as an integral option for most (but not all – see Premiere and the new Framemaker for notable exceptions) of their products. But now Adobe has to think even more broadly and take advantage of the fact that Redmond is really still Client/Server centric. Microsoft make the bulk of their bucks from the Windows stack of XP or Vista desktop OS, the ServerOS , and Office. Then there is smaller in revenue size but a growing array of desktop and server apps that are are tightly coupled to the core Microsoft stack – and they work best only with the Windows stack.
So Adobe has to start to service apps out of the Windows box. Linux appears to be in Adobe plans with rumors of Adobes push into key areas. It should be relatively easy since both Adobe and Macromedia have experience with developing their PDF and Flash Players for Linux and Unix platforms. And the Mac/OS has become Unix certified. I have always said that I will be over to Linux with Windows completely abandoned as soon as Macromedia Dreamweaver and Adobe Photoshop appear on Linux. But even more promising is the whole arena of RIA.
If we look at the classic model of apps there are 3 primary layers:
1-Presentation for for both output and controlling interaction. It used to be that the two were separate but more apps are becoming dynamic where embedded in the output are buttons and controls allowing drilldowns, popups and added queries.
2-Backend persistence is not just for data storage but also the operating performance and setup properties of the ongoing app.
3- Communications for importing/exporting not just data but also receiving events and requests for attention, processing, and stateful determination of what to do next with a whole collection of interacting/co-operationg apps and processes.
Now BPM, ESA and SOA are starting to collect around and define the architectures for doing most of layer 2) and much of layer 3). Adobe with JRun, the PDF and Forms line plus Cold Fusion are partially into these backend layers. But the primary game that Adobe plays in is at the Presentation layer.
Enter Apollo
Heretofore, Adobe has primarily built the tools that provided graphic resources used in assembling web pages, output, and animations supporting other vendors presentation layer frameworks. But with both the Flash player and the Acrobat player, Adobe has been drawn deeper into the Presentation layer with scripting, supporting and controlling interfaces. This has meant menus, dropdowns, text and table fields in both Acrobat and Flash of all things. As a consequence, this has resulted in schizo personalities for both players:
Flash for the designer and/or animator versus Flash for data processing
Acrobat for static, high quality output versus Acrobat for forms and dynamic data collaboration and exchange.
In the case of Flash, Flex appeared to be the rational split off from Flash – use the same player and scripting; but transfer to a whole new development environ which can be devoted to data processing not animation and design tasks. In the case of Acrobat it is still growing. Acrobat does not have the same extremely demanding runtime size constraints that the Flash player which has to run efficiently in a browser and maintain lean and mean client/server interaction.
So in the merge of Acrobat and Flash Player, Flash Player becomes Apollo – the runtime engine that can be used efficiently everywhere as the Presentation frontend for controlling interactions and doing light weight presentations. Meanwhile Acrobat becomes the heavyweight, high quality input and output vehicle that Flash/Apollo can directly use. Here is how Adobe describes the Apollo mission:
Apollo is a cross-OS runtime that allows developers to leverage their existing web development skills (Flash, Flex, HTML, Ajax) to build and deploy desktop Rich Internet/Interface Applications. Here is how they diagram that idea:
Here is what I have managed to pickup from the various Adobe Apollo sites plus Ben Fortas recent Toronto Flex 2/Cold Fusion presentation on interpreting these diagrams.
1 – Apollo will be cross OS platforms running on Linux, Mac, Windows primarily but also targeted for OS and mobile devices where the Flash player currently plays. Because Apollo contains a scripting engine it thus becomes a full time rival to the JVM and Java.
2 – Apollo will be capable of offline desktop or device top, completely background batch, occasionally-connected or completely web based online operation. In addition, this means that Apollo will be able to do local file/IO and RPC-based service calls in controlled operations. Both expand the Flash sandbox and in these perilous security times with Bot/Rootkit/Organized crime based security attacks – there is cause for concern.
3 – Apollo on the desktop will support clipboard, drag and drop, notification, app short cuts, app launch and intercommunications.
4 – Apollo on the web will support standalone operations with direct calls to PDF, HTML/AJAX or other Flash SWF apps. Or as a container in HTML Apollo can call PDF, other Flash, HTML/AJAX apps. This means Apollo apps can be self contained on the web or be part of plain old HTML. This means greater flexibility in fitting Apollo based Flex 2 apps as portals on a HTML web page.
5 – Apollo will use ActionScript 3 which follows very closely JavaScript 2.0 (most browsers support a variant of JavaScript 1.5). There are some major differences between Actionscript 2 and 3, also between JavaScript 1.5 and 2.0. E4X extensions are supported. But conversion from Flex 1.5 to Flex 2.0 and Apollo will require a major rewrite. Therefore Apollo may have a special backward compatible player to run old Flash/Flex and new Flash/Flex. The details are still foggy.
6 – Apollo will output HTML/AJAX/CSS/DOM or Flash code depending on targetted HTML or Flash container just like OpenLaszlo currently does. It is not clear whether Apollo will be dependent on the Adobe Spry AJAX framework.
In sum, Apollo is very ambitious. It is much better than the timid offering that was Macromedia Studio 8 with Dreamweaver still without Visual Drag and Drop forms design tool and source code debugger like competing HTML/CSS/JavaScript, Java, C#/C/C++ IDEs from Eclipse, Microsoft, Oracle, Sun and others. Also Flash 8 served neither designers nor developers well with its pseudo IDE. In contrast, Apollo is bursting with promise.
Apollo and the Promised Land
As you can see there are a lot of implied promises in the Apollo design. And Adobe/Macromedia have moved on a number of them. They have delivered in an Eclipse based IDE, Flex 2 which does Flash development in a visual drag and drop screen design with source code step through debugging. Flex 2 works with Flex Data Services, Cold Fusion, and a host of other Java based servers. But most important of all, Flex 2 is the development vehicle for Apollo. So users will have a robust environ to test and tune Apollo apps which they are already familiar with. Good start.
Second, as noted above, Apollo the Greek Sun god does not shy away from targeting the 6As – IT apps supporting anyone authorized, anytime, anywhere, on any device in any mode (online, offline, background batch or occasionally connected . And it does so in such a way that encourages cross OS, cross device usage with a single source model a la Java. Yet at the sametime this engine provides the very rich media of both Flash and the newly 3D-ized Acrobat.
Third, and most important, Apollo pulls together and it appears Flex 2 supports a fairly open RIA and Presentation layer development paradigm. Developers are getting close to the Holy Grail. Develop once, distribute on all the major OS and desktop platforms, all the major browsers, and a growing list of embedded and mobile devices. Of course, its display hardware dependent – factors such as screen size and event signaling/handling will determine what can be delivered. Yes, I do not expect to be able to plop my big fat greek wedding video control onto my tiny mobile screen. But I do want a more uniform and less device and OS dependent development model for the Presentation layer(DID YOU HEAR THAT IN THE SLEEPY HOLLOWS OF REDMOND). Also I am concerned that Apollo and Flex 2 backend connectors thru XML, HTTP, RPC and Web Services may be a)the first choke point for performance and b)unduly influenced by Adobes own aspirations. In fact, I have a number of reservations, concerns, questions about Flex 2/Apollo overall directions.
The questions outstanding on Flex 2 and Apollo as RIA candidate for serious consideration are:
1 – can Adobe deliver on all the promises made in a timely fashion?
2 – will the code be secure and reliable. The design is fairly sophisticated in allowing more relaxed local usage. Will security or reliability be compromised in the rush to market?
3 – will the code be performant enough ? JavaScript is about 4-8 times slower than Java in most benchmarks. Will Apollo give away even more ?
4 – will all the complex Apollo pieces fit together and still maintain ease of development and deployment ?
5 – will Adobe nickel and dime developers on tool costs and/or admins on deployment costs. The signs are mixed. Oracle gives away JDeveloper and SQL Developer and picks up at the runtime deployment. Ditto for IBM, BEA, and others. I will let users go to the Adobe Flex site and decide for themselves. But it is worthwhile noting that Microsoft won 3-4 major software monopolies in part by assiduously courting developers, developers, developers.
But the bottom line is that Flex2 and Apollo are not only ambitious but also very intelligently designed. This puts Adobe squarely back into the RIA race. And given the prize available, leadership on the broad IT Presentation layer for the next 5-8 years, this is a prize worth contending for.
(c)JBSurveyer 2006
If you liked this, let others know: 
Slashdot 
Digg 
del.icio.us 
reddit 
newsvine 
Y! MyWeb