Does WebSphere Application Server need ObjectGrid? YES!

Billy Newport (IBM Distinguished Engineer and ObjectGrid guru) posted an article on ObjectGrid's non-dependency on WebSphere. Go read it. It will make you smarter than you already are. I thought about the title of his article, and thought I'd post an observation of the obverse: that WebSphere Application Server needs ObjectGrid far more than ObjectGrid needs WebSphere.

What do you mean, you ask? WebSphere can already use OG for session persistence using a simple filter. The serial dependency on a relational database for session persistence is counter-productive from the perspective of availability and scalability. If the DB crashes or fails over, game over man. Game over.

That leaves memory-based replication as an alternative, which in larger environments is really only viable in a client/server topology versus peer-to-peer. Session persistence with OG is far simpler from an administrative perspective, and I expect it is far more scalable particularly with asynchronous replicas.

WebSphere 7 is reportedly much more modular and can use OG to replace DynaCache, though I haven't tried this yet. This makes good strategic sense because DynaCache is local to the application server and more or less specific to caching response objects. ObjectGrid is far more flexible and inherently distributed.

These are starts in the right direction. What I would like to see in WAS 7.next or 8.x is the same modularization that permits replacing the built-in DynaCache with ObjectGrid extended to include the SDO repository and JMS persistence. In fact, any sub-system that currently requires a centralized relational database ought to be capable of using a distributed cache as an alternative.

Ditto Portal, Process, and ESB Server. Commerce Server, I don't know enough about you, but you too. Get rid of the relational database, or at least don't have a serial dependency on it.

While I'm thinking about it, what about security? LDAP in essence uses a constrained tree schema - it's a natural fit for an object cache. Let OG sit between the LDAP server and the app server runtime. I imagine you'd need something conceptually similar to database change notification to ensure cache coherency. I suppose this is mostly doable now if you build your own LTPA module, but I've seen exactly one customer who was willing to do this.