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.
2 comments:
If a good ESB is just a scripting language, then why not just use a scripting language?
I personally like the idea of SOA or ReST enabling back-end systems, then tying the pieces together with easy-to-call script.
Whether ESBs take off or not, the work to enable data access to back end systems will probably always pay off.
My point was, as with anything in engineering, there are always tradeoffs in how you implement your solution. If it came across as equivocating, let me be clear:
1. The future of integration programming resides with higher level languages, like scripting languages.
2. You can do a great job rolling your own integration environment with standard languages & assorted tools. But not everyone knows how to.
3. You can purchase a vendor product that ties a scripting language with a compbination of open source and proprietary tools.
This latter thing is what AquaLogic arguably does. I don't need to use CVS or SVN to manage rollaback of my scripts, for example, it's built into ALSB. I don't have to use a dependency analysis tool to figure out what breaks on a change, that's built into ALSB. I don't need to build my own management API, I have one exposed through ALSB that I can use with Jython.
To me, ESBs are productivity tools. I have not seen them used (with any technology!) as a centralized hub for a long term period. Yet, I've seen teams cut schedules down 40%+ for integration projects with ALSB that would have otherwise used WebLogic Server and Java. The point is that it doesn't give your SOA mystical powers. You still need to consider WHAT services to expose that actually do something useful for your organization, what architectural style you want to use, governance, etc.
Post a Comment