Stu Charlton of BEA says stuff on the ESB brouhaha, but then he says some really crucial stuff we all need to consider...
I like ESBs if they're used properly -- to me, a good ESB is actually just a scripting language with supporting infrastructure. AquaLogic Service Bus, to me, is a Pipeline language, an XQuery language, and the supporting management & interoperability infrastructure, for example. But an ESB is not mandatory, and sometimes can slow you down if you're not looking to make legacy systems interoperate.Wow. Equating Aqualogic with a scripting language. That's bold.
I agree with Steve Vinoski's The ESB Question. Don't use an ESB if it's going to slow you down. ESBs are a decent, productive tool for SOA (and even REST!) when applied properly, but so are Python or Ruby. ;-)I want to like what Stu's saying, but his sprinkling of "properlies" just seems like equivocation.
BEA tries really hard to make Jython supported in WebLogic and AquaLogic, for example. The whole JMX object model is scriptable, and you can do some amazing things with it. And we have PHP running on WebLogic Server.OK. I kicked the tires on Aqualogic over a year ago. I did not appreciate it any more than other ESBs, and found Jini/Javaspaces significantly more productive.
But I like the parts about Jython and PHP.
What gives? Perhaps two things:Yeah, across the industry we pretty much have #2 at the level of a high art.
We've fixed #2 with hardware platforms. SOA was supposed to fix it for software, but perhaps not (yet).
- software has long term residual value but our investment decisions are always short term
- we intertwingle what changes from what doesn't change
As for SOA, well. It's well known...
SOA is the only thing Chuck Norris can't kill...Now we get to where I really like what Stu writes (and it has nothing to do with ESBs, unsurprisingly)...
Its too bad you can't afford it.
I've seen many fast-moving IT departments, particularly in investment banking, but even some in telecom, continue to use the "build it to throw it away" mantra with reasonable success. This works when your organization is compartmentalized. But when information sharing is of primary importance, such as the intelligence or defense establishment, for example, we get to a case where these huge organizations need a different approach. Layers upon layers of bureaucracy make it hard to abandon any pet project.Every branch of software I know of must build an organization that is good at building software that is easy to throw away. If your organization can do this, it is at the master level and should be highly valued. Very few organizations can throw away much of anything in their data centers. This is *horrible*.
This is partly why I think Enterprise Social Computing, the Web's architecture (or some successor of REST), etc. are very exciting; they seem much more likely to strike a balance between shared agreement and decentralized execution.
Stu nails that. But moreover he latches onto what should remain relatively constant in the data center: the information (web) architecture. That seems to be a good way, as he writes, "to strike a balance between shared agreement and decentralized execution". If you do that properly, you win.
That BEA Enterprise Social Computing thing looks interesting. It's encouraging to see BEA reaching out in that direction.