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. :)


    Wednesday, November 17, 2004

    ActiveGrid Comes out of Stealth

    After 18 months of hard work, ActiveGrid is finally out of stealth mode! Check it out at:


    There are details about the ActiveGrid Grid Application Server and about Adaptive Transactions, a new technology we are introducing to add intelligence into the execution of transactional applications on large grids.

    Friday, November 12, 2004

    "Local" Web Services

    In a world where applications are increasingly being defined by declarative XML like BPEL, XForms, XPath, it is becoming cumbersome and complicated to incorporate all of those definitions into procedural applications. But perhaps the tail has been wagging the dog. If the flow of an application, the interface points to external entities, its user interface, and its queries are all defined in XML, perhaps it is time to simply admit that the application is written primarily in XML and that logic must be integrated with the XML defined application, not the other way around!

    Of course the obvious integration point for such an architecture is web services, which clearly is not ideally suited for adding snippets of code or for having a bunch of internal methods that call each other and share the same dataset. What is needed is a method to have a web service that is treated like a local method call, much like in the CORBA days there was a way to do a local IIOP call.

    The concept of Local Web Services is simple - procedural code that has XML Schema defined inputs and outputs. If Local Web Services that are calling each other are written in the same language and running in the same address space, they can simply call each other without having to do any type mapping, there will simply be a layer of indirection.

    If Local Web Services are written in different languages and/or running in different address spaces, they go through an XML Schema translation mapping to call each other. And if a Local Web Services need to become a remotable web service, they can easily be upleveled into a real web service since they are already using XML Schema defined inputs and outputs.

    The benefit is that all of the code now uses the same development paradigm and it can be easily implemented as a local call, local call to another process, or a remotable call. And it fits in very well into a world where a service-oriented application is defined by declarative XML.