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.

Why I'm hopeful about the future of energy

From HuffPo:

When talk turns to biofuels, it often soon turns to food shortages next. Biofuel doesn't have to be made from food staple crops, though.

Here are five unexpected potential biofuels:

Giant Grass:
Giant Grass, also known as Elephant Grass or Miscanthus, yields twice the amount of ethanol per acre than corn or switchgrass ethanol in one quarter of the space.

Miscanthus, for instance, is able to grow on land too marginal for crop production, so it doesn't have to compete with land for food crops. It also doesn't require major input or fertilization after planting and once established will yield for around 15 years.

Agave:
No longer known solely as the main ingredient in tequila or agave nectar, Mexican scientists began to test the viability of the agave plant as a potential ethanol producer. Scientists estimate that agave can produce up to 2,000 gallons of ethanol per acre per year and increase to 18,000 gallons if the plant's cellulose is processed. The plant is also praised for its durability.

Algae:
Sapphire Energy, a biopetroleum producer, boasts a renewable, high-octane diesel made from algae called Green Crude that is chemically identical to gasoline.

"The resulting gasoline is completely compatible with current infrastructure, meaning absolutely no change to consumer's cars." This is of course in addition to the benefit that their Green Crude is a carbon neutral fuel.

Kudzu:
The kudzu plant, which is also known as "the plant that ate the South" grows vigorously in the United States at a rate of 6.5 feet a week.

Researchers estimate that kudzu could produce 2.2 to 5.3 tons of carbohydrate per acre in much of the South, or about 270 gallons per acre of ethanol, which is comparable to the yield for corn of 210 to 320 gallons per acre. They recently published their findings in Biomass and Bioenergy.

Sugarcane-Giant Grass Hybrid:
Giok Se Tijong created Tijong grass, a sugarcane- giant grass hybrid plant in his homeland of Indonesia in the 1950's as quality cattle feed. Recently, the retired minister was inspired to test his plant for it's biofuel potential.

Preliminary tests show that the grass has a high carbohydrate content (71.26%) and Tijong has produced ethanol from it in his home laboratory, but he has yet to receive enough backing to do much more.

-----

I don't know about diverting the tequila food stocks to fuel, but bio-diesel from algae that's chemically identical to dino-gas makes me giddy.

Non-tech musing

I have a life philosophy to live life without regrets. Jump off the high dive. Go surprise your Mom for lunch. Hug your kids until they make you stop.

I had a dream last night. I dreamed I went back to my alma mater. We had an untimely parting. This is one of the biggest regrets I thought I had.

In any case, I was walking around campus when I woke up. I came to a realization in those early minutes of my day. I would not be where I am today had I finished my degree. I would be in a very different place. I would not be married to the most wonderful woman and I wouldn't be father to my two little rapscallions.

So, here's the musing. Make a list of the top five big regrets of your life. Draw a line from the consequences of those regretful events to where you are right now. See if you would be better off in the biggest picture sense had that sequence of events not materialized. This isn't intended to be an exercise in temporal causality. It's metaphysics I suppose, not the other kind.

My guess is you wouldn't be where you are, and you will realize that even regrets can be blessings. You get to then stop referring to these things as regrets, and instead think of them as happy accidents.

BEA and Oracle

The Zealot is off to Denver today to meet with some Oracle execs about the BEA acquisition. Finally, Oracle figured out that Oracle App Server is - well, junk. Perhaps junk is too harsh. It leaves some things to be desired. Like market share and ISV support. At any rate, for the low, low price of $8B+, they're getting some solid technology. This pleases me because the synergistic potential of these combined companies is fairly impressive.

The Reg had an article this morning with new roadmappery. Most interesting to me, WebLogic will pick up Coherence. Bundling details are forthcoming I'm sure, but I do hope IBM takes notice. WebSphere ND/XD would be even more formidable if a couple of things happen:

1) Someone fires the illiterate 15 year olds running IBM marketing. WebSphere eXtreme Scale? I bite my thumb at thee. Don't get me started on what they've done to the venerable AS/400.

2) ObjectGrid/Data Grid/WXS gets bundled into both ND and XD. I believe it has to happen. It's beautiful technology, and Billy Newport's team just put out a major new release with some uber cool functionality. Compute Grid should be a part of XD, and of course keep the advanced workload management and autonomics of WebSphere (pardon me whilst I vomit) Virtual Enterprise.

and finally,

3) Stop the product catalog sprawl. Period. XD should be XD. ND should be ND. Splitting XD into three distinct product codes is a mistake, because it's a nickel and dime disincentive to go whole hog. Oracle doesn't get this. They never have, I don't think they ever will.


These things have got to happen to compete against the new Oracle.

Database Sharding

Great primer on database sharding...

Explaining XTP to the business consumer

How do you make the case for something that is so highly technical as extreme transaction processing, when you are conversing with a mostly non-technical crowd? I've puzzled about this for a while now. I think the only way to do this effectively is to talk about the approach in an abstract sense and relate the return to something tangible to the particular crowd. For the business, it comes down to dollars and competitive differentiation. They neither care nor can conceive of the design differences between 500 tps and 50,000 tps request processing.

I wrote a fine 100+ page document for a customer outlining their 5 year IT strategy plan, which is largely centered on XTP and a couple of other things. Sure, extreme transaction processing is typically the domain of "extreme" volume. But, invert the design plan, and you get efficient transaction processing - the most bang for the least bucks. We're talking about taking monkey work out of the extraordinarily expensive data tier and letting the much less expensive app tier keep a copy of the data it most frequently needs. Think "scale-down computing". Take one machine, make it do as much as it possibly can, and continue deploying until you meet your SLAs. In so doing, we avoid the need to make bigger the really expensive parts of our environment (mainframes, RDBMS, SAN, etc) until there is absolutely no other course of action.

A ha. Now we're getting somewhere.

In the unlikely event that someone is actually reading this, does that make sense to you?

The best laid plans of mice and men

My bad. Start a blog, don't post anything since the inaugural message, step 3, profit.

It didn't work. I'll try harder now.

WAS 7.0, SLES 10, Xen, and a petroglyph of a laptop

New toys to play with...

So, I managed to find an older T41 lappy that was doing a whole lot of nothing. I also found a DVD of SLES 10. With a bit of spare time on my hands, I now have a lab. Yay me.

Why do you care? Well, this is the second post on this blog, so you probably don't. But, I needed a sounding board to get some of the ticklers out of my brain. There's too much noise up there.

I have a theory that some of the overhead we see with WebSphere (and BEA, IIS, and any other highly threaded workloads) on VMWare will be dramatically less if we use the Xen hypervisor instead. It has to do with what I call 'the scheduled scheduler' problem. Basically, Xen's paravirtualization approach uses an integrated global scheduler for all of the guests. (It's not quite that simple, but this is an adequate explanation for now.) This is basically similar to pSeries LPARs in some respects, and AIX 6.1 WPARs in other respects.

On the other hand, VMWare ESX schedules guests based on various WLM weightings, and the guests in turn have their own schedulers. Like a small gear turning a big gear, it takes longer for the scheduled scheduler to schedule each of the workload threads.

So, my goal is to build out a benchmark environment on this T41. It has enough memory to be functional, but the CPU is nothing to write home about. I'm going to load WAS into the base OS as the control group, and WAS into a single Xen guest as the variable. I'll compare the performance of the control versus the variable groups and see what shakes out. Should be interesting, if you're sick like me.

In other news, WAS ND 7.0 is now in beta. Dare I use it for the Xen benchmark? Meh, we'll see.