Wednesday, November 24, 2004


We at ActiveGrid were a bit suprised by the ruckus up on Slashdot via Phil Wainewright's blog posting on Loosely Coupled J2EE: no longer required. I am sure Phil was just as suprised, since the article he is quoting from is one I posted over 15 months ago, entitled Application Servers 2004: A Big Muffin in a Donut World. It was hilarious to have things pointed out, like that "Grid Application Server for LAMP = GASLAMP".

First off, I want to say that I think that Java is a great language. Like many, I wish that Java was open sourced and benefited directly from the innovation of projects like Log4J, Struts, Hibernate, etc. I would also like it if Java had a better XML binding such that there wouldn't have to be JSRs to have a standard binding to things like SAML and BPEL. And I would really like it if Java's support of typeless objects went beyond JSR's like generics and more towards a full embrace of projects like Groovy!

I also think that J2EE is great at what it was built to do, and I spent a good chunk of my career making J2EE successful. There are applications for which J2EE is incredibly well suited, and the breadth of J2EE enables developers to create a lot of different types of applications, ranging from basic web applications to complete ERP systems.

We are focusing the ActiveGrid Grid Application Server on ONE SPECIFIC kind of application, that has the following requirements:

  • Integrate with and minimize connections to existing systems, including J2EE.

  • Deploy specifically on Linux clusters running the LAMP stack.

  • Scale seamlessly from 1 to 1000 machines.

  • Consume a lot of XML.

  • Produce a lot of XML and HTML.

  • Our bet is that more and more applications will have the above requirements, and that our solution will run these specific kinds of applications better than a general purpose architecture like J2EE. Time will tell. :)


    1 comment:

    luke said...


    I was hugely interested by Phil's blog post, and first learned of GASLAMP that way.

    Maybe you could make a post explaining the exact area that GASLAMP fits into in a typical n-tier architecture software program - facilitating each of the tiers and their components to speak to others on top of a powerful middleware platform?