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.

    Saturday, April 10, 2004

    Sun and Linux, Sun and IBM

    My one year anniversary of leaving Sun is coming up in a couple of weeks, and the company has definitely come up with some interesting things to reflect on lately.

    Sun and Linux

    There is yet another massive reorg and layoff underway, with the promise that moving people around will fix things, but there is no response to what customers and analysts have been asking for years: What's Sun's Linux strategy? You ask five Sun employees this question and you get five different answers. In effect, there is no Linux strategy. Begrudgingly shipping Linux while touting Solaris x86 is not an effective strategy, and it definitely is not a market-focused strategy.

    In the last year, Sun had the opportunity to become the leading Linux vendor for two reasons:

    1. SuSe was for sale for $220M and Ximian for $20M. Novell bought both of these companies and went from a forgotten company to an emerging Linux star. Sun could have very easily used some of its cash horde to buy both of these companies and been in the same position. And it would have dovetailed very nicely with the AMD chip deal they struck.

    2. But the biggest thing Sun had going for it was a full Unix System V license that it had purchased from AT&T in the early 90s. With the SCO lawsuit going on, Sun could have bought SuSe and been the only ones selling an unencumbered Linux. Instead, Sun chose to side with SCO and promote Solaris x86 over Linux and make glib comments about Linux's legal problems.

    The irony is that Sun has to give the proprietary Solaris x86 away for free and still no one wants it, when instead they could be selling the open source SuSe Enterprise Server. It will be interesting to see how far down the road Sun will go with the Solaris x86 vs. Linux strategy and whether it will make a U-turn before it drives off a cliff. Sun has repeatedly stated that its future lies in higher level software like the Java Enterprise System and services - so why swim against the tide on the underlying commodity operating system?

    Sun and IBM

    I have long been curious as to why Sun has not been sold to IBM. I imagine that McNealy has refused this type of discussion to date, but clearly McNealy's strategy has been flawed with 12 consecutive quarters of decreasing revenue whilst competitors such as IBM, HP, and Dell have increasing server revenue. There is no doubt that the board forced him to lay more people off, promote a COO, and settle with Microsoft, which are all things that McNealy had said would not happen. A board with even the slightest sense of fiduciary responsiblity has got to be looking for an exit strategy at this point.

    A couple of years ago, IBM bought Informix's database business for $1B in cash just to upgrade the customers to DB2. Sun's market cap is $14B with $8B in the bank, so it is only worth $6B. It has $11B in annual revenue. IBM trades at roughly 1.5x annual revenue, so a $26B offer ($18B plus Sun's $8B in cash) is an 85% premium for Sun AND is an accretive acquisition for IBM!

    IBM could put a SPARC to PowerPC microcode translator in front of a PowerPC pipeline and have a faster processor for all of the Sun customers to upgrade to than anything on the Sun roadmap (in the early 90's IBM had an x86 to PowerPC microcode translator implemented in the never shipped PowerPC 610). Open source Java, put Solaris onto a Linux transition plan just like AIX, migrate the few software customers to WebSphere, and mission accomplished. And as an added bonus, IBM would get a full Unix System V license and clean up their SCO problem.

    How sad it is that it had to come to this.