2005-04-11
An Early, Quick Look at ActiveGrid
ActiveGrid just released the early-access version of their application builder and grid application server. The specifics of this open source grid-based web system had been kept under wraps since last November; CEO Pater Yared dropped hints about a Google-inspired system built on LAMP (Linux, Apache, PHP/Perl/Python) for delivering scalable web apps. I say "Google-inspired" because ActiveGrid pays a lot of attention to scaling web apps across a grid of commodity computers (minimum hardware: 800+ MHz x86 processor, 1 GB RAM, 10 GB hard drive). ActiveGrid allows six deployment patterns, most of them focused on high-availability. The grid application server is implemented as an Apache module with libraries that run within language-specific modules (mod_python, mod_php, mod_perl, tomcat).
The early-access demo (version 0.6) is a nice IDE. When you start, you can dive right into a Python Pet Store and see how the ActiveGrid IDE tries to shield the developer from the array of acronyms (BPEL, XML, XForms, XPath). The business workflow is handled in Business Process Execution Language (BPEL), a XML standard that defines application flow. Rather than tax the developer with the markup, ActiveGrid provides a graphical interface. (Image below shamelessly linked from ActiveGrid's website.) 
My first reaction: Cool! My second reaction: what happens when the application flow is complicated, when there are many conditionals? Does the graphical interface become more unwieldy than nice domain specific language, like we get in Rails? I'm guessing that at some point, you'd want to drop down into code, and it would be a combination of the BPEL XML and WSDL and whatever you use for application logic. Although ActiveGrid got a lot of buzz for its promise of enterprise scalability for the "P" part of LAMP, their product allows coding in Java and even C/C++. ActiveGrid allows you to use an appropriate language for each task (web service), and when I e-mailed the CEO a while back, he mentioned that after Python, PHP, and Perl (in that order), they'll be looking at other languages like Groovy and Ruby.
I'm quite content with the Ruby on Rails framework. While ActiveGrid's focus on scalability is impressive, the need to deal with all those standards -- even with the help of their IDE -- and the lack of production readiness makes it unsuitable for version 1 of Writertopia. It makes sense, though, to keep track of ActiveGrid's progress and see how their system provides high availability.
Update 5/7/2005: Peter Yared let me know that release 1.0 will support nested flows in the process editor, so developers can drill down into components. That seems like a good way to handle complexity in a graphical design system.
Update 5/14/2005: While walking in a thunderstorm and listening to Scott Mace's interview with Peter Yared, I was surprised to hear this very blog entry referenced. Specifically, Mace asked Yared one of my questions above: "what happens when the application flow is complicated, when there are many conditionals?" Although this didn't include the more central question I had on using a graphical editor, Yared's response was kind of interesting:
"Especially when you have an application flow that's very complicated and has a lot of conditionals, that's when you want to define it in something like BPEL, and not have it hard coded into an application. You don't want this kind of stuff hard coded because you'll never be able to dig out what was happening. You know, even the programmer who programmed it goes back two days later and can't figure out what's going on. That's why people are moving to things like BPEL."
I'll dismiss the example of programmers forgetting what they coded in two days. That was probably hyperbole for effect. I'm also not sure what "hard coded" means, given that BPEL code lives in a file somewhere too. Application flow in Ruby on Rails uses easily readable code, a domain specific language, in easily located files (the controller parts of MVC).
But the idea of BPEL as an ideal application flow language makes me want to learn a little more about BPEL. A little Googling turned up this nice article on BPEL and Java. The author thinks "BPEL is thus comparable to general purpose programming language such as Java, but it is not as powerful as Java." And since some fans of Ruby think that Ruby >>> Java, by transitive property, I think it's fair to assume Ruby is a much better general language than BPEL :) This notion is reinforced by my belief that design by committee is not a good way to design an elegant language. The more complicated application flow gets -- well, the more complicated any piece of code gets, the more it makes sense to use an elegant and powerful language and build up your solution from that language. From the above article and the discussion on TheServerSide, I think there's a sweet spot for BPEL, but it's probably not the web app I'm building.
Looking at BPEL code, I don't find the idea of coding in it appealing aesthetically (hence the graphical editor). Matjaz Juric, the author of the BPEL and Java article, finds a number of advantages to using BPEL, particularly support for business process features like long-running transactions. So, I'll withhold judgement on whether the ActiveGrid approach makes sense for B2C web apps like Backpack (or flickr) until I learn a little more about "programming in the large," declarative programming, and how ActiveGrid customers feel about BPEL.
My first reaction: Cool! My second reaction: what happens when the application flow is complicated, when there are many conditionals? Does the graphical interface become more unwieldy than nice domain specific language, like we get in Rails? I'm guessing that at some point, you'd want to drop down into code, and it would be a combination of the BPEL XML and WSDL and whatever you use for application logic. Although ActiveGrid got a lot of buzz for its promise of enterprise scalability for the "P" part of LAMP, their product allows coding in Java and even C/C++. ActiveGrid allows you to use an appropriate language for each task (web service), and when I e-mailed the CEO a while back, he mentioned that after Python, PHP, and Perl (in that order), they'll be looking at other languages like Groovy and Ruby.
I'm quite content with the Ruby on Rails framework. While ActiveGrid's focus on scalability is impressive, the need to deal with all those standards -- even with the help of their IDE -- and the lack of production readiness makes it unsuitable for version 1 of Writertopia. It makes sense, though, to keep track of ActiveGrid's progress and see how their system provides high availability.
Update 5/7/2005: Peter Yared let me know that release 1.0 will support nested flows in the process editor, so developers can drill down into components. That seems like a good way to handle complexity in a graphical design system.
Update 5/14/2005: While walking in a thunderstorm and listening to Scott Mace's interview with Peter Yared, I was surprised to hear this very blog entry referenced. Specifically, Mace asked Yared one of my questions above: "what happens when the application flow is complicated, when there are many conditionals?" Although this didn't include the more central question I had on using a graphical editor, Yared's response was kind of interesting:
"Especially when you have an application flow that's very complicated and has a lot of conditionals, that's when you want to define it in something like BPEL, and not have it hard coded into an application. You don't want this kind of stuff hard coded because you'll never be able to dig out what was happening. You know, even the programmer who programmed it goes back two days later and can't figure out what's going on. That's why people are moving to things like BPEL."
I'll dismiss the example of programmers forgetting what they coded in two days. That was probably hyperbole for effect. I'm also not sure what "hard coded" means, given that BPEL code lives in a file somewhere too. Application flow in Ruby on Rails uses easily readable code, a domain specific language, in easily located files (the controller parts of MVC).
But the idea of BPEL as an ideal application flow language makes me want to learn a little more about BPEL. A little Googling turned up this nice article on BPEL and Java. The author thinks "BPEL is thus comparable to general purpose programming language such as Java, but it is not as powerful as Java." And since some fans of Ruby think that Ruby >>> Java, by transitive property, I think it's fair to assume Ruby is a much better general language than BPEL :) This notion is reinforced by my belief that design by committee is not a good way to design an elegant language. The more complicated application flow gets -- well, the more complicated any piece of code gets, the more it makes sense to use an elegant and powerful language and build up your solution from that language. From the above article and the discussion on TheServerSide, I think there's a sweet spot for BPEL, but it's probably not the web app I'm building.
Looking at BPEL code, I don't find the idea of coding in it appealing aesthetically (hence the graphical editor). Matjaz Juric, the author of the BPEL and Java article, finds a number of advantages to using BPEL, particularly support for business process features like long-running transactions. So, I'll withhold judgement on whether the ActiveGrid approach makes sense for B2C web apps like Backpack (or flickr) until I learn a little more about "programming in the large," declarative programming, and how ActiveGrid customers feel about BPEL.
