by Phil Brock
introNetworks is a software company that hosts online communities for companies and organizations using a unique Web 2.0 platform. If you attended the Adobe MAX 2006, you probably used the intronetwork application that we configured specifically for that event. The engineering team at introNetworks is currently implementing the sixth generation of our platform — code-named Samurai. As vice president of engineering, I am responsible for architecting the three-tier client-server platform, for managing the team of seasoned programmers, and for making the hard technical decisions — with the advice of my team. The team has only been together for a little more than a year and is composed of .NET, C#, and SQL programmers, a LAMP expert, and an Adobe Flash® programmer.
In this article, I discuss how our engineering team adopted Adobe Flex™ Builder™ 2 and successfully migrated from the ActionScript™ 2.0 language to ActionScript 3.0 to build several applications that look, feel, and perform like desktop applications.
Our current fifth-generation (V5) platform contains our main intronetwork application, several other customer and user-facing applications, some web services, and a database. The intronetwork application was written entirely in ActionScript 2.0 (targeting Flash Player versions 7 and higher) but the other client-facing applications were written in Ajax. The Ajax applications, when compared to the Flash application, suffer from a diminished look and feel, and they are harder to develop, debug, and maintain.
With Samurai, we wanted all our client-facing applications to share the same look, feel, and programming language. This also simplified the overall platform architecture. Our LAMP expert was going to have to learn a new language one way or another, so it was just a question of whether he should learn C# or Flex and ActionScript. Since Ajax was not an alternative and we had hit the performance boundaries of ActionScript 2.0, we decided to look at the beta version of Flex. What we saw was a cool Eclipse-based IDE in Flex Builder 2, rapid visual component layout in MXML, a powerful object-oriented (OO) language in ActionScript 3.0, and novel ways to manage XML in E4X. However, we needed to research how several desired platform architecture features might be implemented with Flex. We had already wireframed (produced snapshot images of) the new GUI for our main intronetwork application, and we had some ideas about how we wanted that to be internally architected using plug-ins.
To kick-start the research, Ted Patrick — a Flex evangelist from Adobe — spent two days showing us how our desired architecture and application features could be easily implemented with Flex. We had some spirited conversations with Ted, discussing things at a conceptual level and then diving into coding details and Flex methodologies on how they could be accomplished. Learning a new programming language and IDE was not a hurdle to the engineering team since most of us have had to learn many over our professional lifetimes. The hurdle we faced, and quickly got over, was implementing the features we needed the right way the first time. That saves a lot of pain down the development road.
Our Flash developer easily grasped the new features in ActionScript 3.0, but the amazement came from the C# and LAMP developers when they realized how powerful ActionScript 3.0 is. All the major OO concepts (class inheritance, error handling, delegates/callbacks, pointers, and data binding) are there, as is runtime typing. With the additional MXML layout capabilities and web service objects, we had a clear way to architect our Flex applications as a series of (abstract) functional layers that would even allow the Flex engineers to work together on the same application without stepping on each other's toes. Modular application development is just what we experienced old-timers prefer.
There was another issue, though. Any Web 2.0 platform typically must incorporate some robust reporting and charting functionality for customers to monitor their site. This has been one of our competitive advantages with the last two versions of our platform. The .NET/Ajax environment offers several options, but how could we solve this with Flex? The answer: Flex Charting. Flex Builder includes a library of charts and graphs that we can easily drag into the design workspace and connect to our back-end data source. With the ability to add charts and increase the visual richness of our applications, we were more determined to standardize on the Flex development environment.
After several months, we have reengineered our primary intronetwork application and successfully proven and tested the new architecture. The intronetwork application is now completely data driven and is built atop a plug-in architecture for the purposes of localization, flexibility, performance, and efficiency. E4X provides unparalleled integration with XML served up from middle-tier web services and significantly reduces the time it takes to program this component of a client application.
In designing and developing our other customer-facing applications, we have actually changed one aspect of our product development methodology precisely because of Flex Builder. When prototyping our GUI-based applications in the past, we went from feature specifications and whiteboard sessions to wireframes and then finally to ActionScript or Ajax. Now Flex Builder enables us to develop GUIs so quickly that we skip the wireframe step altogether and go directly from whiteboard sessions to Flex Builder — saving time and enabling us to get better feedback on the end-user experience earlier in the development process.
Flex is also changing the way we think about our platform deployment. Web 2.0 applications have been primarily about browser-based applications. If an end user or customer is not connected, the application is not available. Additionally, some of our in-house (platform) tools were desktop applications written in C#. These two issues have spurred us to evaluate Adobe's recent development of Adobe® Integrated Runtime (AIR). With some of our custom customer development work, we have developed an Adobe® AIR™ application to better understand the differences between Flex applications and Adobe AIR applications, and how those differences positively and negatively affect our software development process. One advantage is that there is no overhead in reusing our Flex-based components and modules in an Adobe AIR application. This gives us tremendous flexibility in how we package and deploy our products from both a business model perspective as well as a software architecture perspective.
If service-oriented architecture (SOA) continues to evolve, I can foresee a time in the not too distant future when rich Internet applications (RIAs) are quickly assembled from existing plug-in components or modules. Modular GUI components — written in Flex or ActionScript — sit atop corresponding SOA-based (data) components and represent the GUI atop the SOA data. These components could potentially be cross-vendor, cross-corporation, or cross–company department components that connect to create snap-together RIAs.
At introNetworks, our engineering team has successfully assimilated ActionScript 3.0 and Flex Builder and is blazing away on implementation. Everybody wants to work in Flex Builder. We are proving Anthony Franco correct (see EffectiveUI and the eBay Desktop prototype in the March/April 2007 issue of the Edge) as we C, C++, and C# developers migrate to Flex. But I believe we prove his point even more deeply since we were C# developers who were fed up with the limitations of ASP.NET and Ajax. We can now build RIAs with the features, look and feel, and efficient architectures of a desktop application across browsers and operating systems. We are already finding ways to use Adobe AIR, and I am sure it will become more integral to our product in the not so distant future.
Phil Brock is vice president of engineering for introNetworks Inc., which creates hosted and customized solutions for online communities.