Back in 1998 I built a mission-critical application using the technology suite now called LAMP (Linux, Apache, MySQL, and Perl/PHP/Python). It was a killer combination: blazing performance, rock-solid reliability, rapid development. Perl's dynamism was an essential ingredient, but looking back, I see it was also a crutch. If I had needed to redeploy to a cluster, swap in a different authentication scheme, or alter the flow of the application, I'd have been able to do those things quickly, but it would have been harder for somebody else to.
Marrying the flexibility of procedural coding with the different kind of flexibility afforded by declarative techniques is a key challenge for all developers. In the J2EE world, the JBoss folks are talking about "aspect-oriented programming" and "crosscutting behavior." It's buzzword-intensive stuff, but the idea is clear: Certain properties of applications -- for example, caching, asynchronous communication, and authentication -- shouldn't be hard-coded. Instead, they should be declared outside the code and made subject to administrative control.
Microsoft has been doing similar things for a long time. Back in the 1990s its COM+ technology introduced a set of declarative mechanisms. The forthcoming Indigo extends that approach to .Net and adapts it to the world of XML Web services.
Somebody was bound to bring these ideas to the LAMP platform, and now somebody has: ActiveGrid. I had read about the company a while ago, and Scott Mace's interview with CEO Peter Yared prompted me to download and tire-kick the early-access release of its software. ActiveGrid's goal is to enable a LAMP application to scale out from one commodity box to hundreds while making deployment patterns not just declarative but also adaptive. A session-replication feature, for example, might be activated selectively and on the fly for a priority customer. That's a neat idea, although it's merely sketched out in the current version of ActiveGrid's Apache/Python-based "grid application server."
Applications are created in the ActiveGrid Application Builder, a visual development environment. Because it's based on the wxPython GUI framework for Python, it runs on both Windows and Linux desktops. Because a simplified deployment environment is available within the tool, you can develop and debug locally.
The tool provides graphical editors that describe connections to data, basic CRUD (create, retrieve, update, delete) logic, and page-to-page flow. The wizards store all these descriptions in a file that contains a mixture of two emerging XML vocabularies: BPEL (Business Process Execution Language) describes the application's flow, and XForms describes interactions with data.
The development and deployment systems then render these descriptions, in theory adapting them for varying presentation layers (for example, simple vs. DHTML), as well as for varying deployment patterns. Python -- or another dynamic language, such as PHP -- is reserved for its highest and best use: the business logic.
ActiveGrid's BPEL/XForms application descriptions are a curious hybrid that may or may not appeal to developers or other tool vendors. But if the overall approach reduces the rocket science required to scale LAMP applications onto commodity clusters, enterprises may come to see LAMP in a whole new light.