Reactions to the ESB Question
October 4th, 2007 | Published in enterprise, integration, REST, services, WS-* | 4 Comments | Bookmark on Pinboard.in
Comments and reactions to my previous post have been interesting. Rather than responding to comments by adding more comments to that post, let me address them here:
- Mark says what I’m recommending isn’t entirely new. And you know what: he’s exactly right! What might be interesting, though, is why he’s right. I pushed these ideas surrounding REST and dynamic languages for a number of years in my former position before finally leaving that position, partly because those ideas were not getting the level of attention I felt they deserved. So yes, the ideas are certainly nothing new today, but they were reasonably new back then.
- REST is unproven. Sigh. I can’t decide if people say this because they’re just trying to stir up an argument, or they’re so heavily biased toward their non-REST approaches that they just can’t even consider that there might be viable alternatives, or they really have no clue about what REST is, how it works, and why it works, and they’re not interested in learning it, so they just react badly whenever they hear it, or all of the above. If you’re anti-REST or REST-ignorant, and you haven’t read RESTful Web Services, then don’t even talk to me about REST. The book is absolutely wonderful, and its explanations and answers are extremely clear. If you consider yourself informed and capable when it comes to distributed systems and integration, but you don’t know REST, then there’s simply no way you can read that book and not have it lead you to seriously question your core beliefs regarding how you think such systems should be built, unless you’re completely close-minded of course.
- Are you saying we should throw everything out and redo it with REST and dynamic languages? No, not at all. I would never advocate wholesale rip-and-replace, because the cure is almost always worse than the disease. I’m simply saying that many integration projects can be done easier and with less expense if you use those tools and approaches (and please notice I said “many,” not “all”).
- Steve’s thrown out the baby with the bathwater. It seems that people might not have read my entire post, because a number seem to think I said that ESBs should never be used at all. That’s not what I said; if you read all the way to the bottom, you’ll see that I explained some conditions under which I thought they can come in mighty handy.
- What do mono-language programmers have to do with ESBs? It’s all part of the same culture, the “one size fits all” approach, where you have answers looking for problems rather than the other way around, and where people intentionally wear blinders to less expensive, more productive, and far more flexible and agile approaches because “it’s just not the way we do things around here.”
- Are you seriously recommending dynamic languages for enterprise integration projects?! Hmm, that’s mighty enterprisey of you to ask that. Yes, that’s exactly what I’m recommending, because they’re solid, fast, flexible, smaller and therefore less buggy, easily deployed, easily maintained, and the solutions you get by using them will be in production well ahead of your traditional compiled languages.
At the end of the day, if you want to ignore my advice on using REST and dynamic languages, that’s your own problem. You won’t get any arguments from me, because I’m not in that business anymore. All I know is that I’m using them very successfully as part of what I’m working on these days, and it’s simply glorious.
October 5th, 2007 at 2:59 am (#)
Steve,
I did read all you post. I thought the ESB usage scenarios you mentioned were a little thin. and as I said in my post if you drop the presumption that the ESB will be the end-all solution you get a very usable piece of middleware
REST is not the end-all solution just as much as ESBs
Arnon
October 5th, 2007 at 10:20 am (#)
:/ I don’t think dynamic languages are more easily deployed. I’ve wasted countless hours trying to get perl modules from CPAN to compile. And what if I am forced to write a bunch of perl code on a windows machine that I must then deploy to a unix environment? I get shivers even thinking about it, and I suspect the same problem exists in the Ruby world… not to mention getting your apache environment up and running with mod_perl is a complete nightmare, and usually breaks something else in the process (like your php setup). I’ve written a ton of perl. My opinion is it’s nice for simple things, but a nightmare for anything else.
Java works very well. It’s “write once run anywhere” mantra is true for the most part, especially now that dependency injection is becoming the norm. And how can you argue with zipping up your webapp as a war, dropping it into a webapps directory, and just watching it fire up? And really, if you want it, Java has a dynamic language and rails’ish environment too: Groovy and Grails. I’ve used both, they are great, and you can just drop a Grails app right into your webapps directory too. All of Grails DSLs are done in Groovy, so you can avoid XML hell, and I definitely agree XML hell is hell.
And why is it that whenever I see REST come up, it turns into an argument against compiled languages? The Java Restlet framework is awesome, and easy to get going. Grails also makes REST easy.
-Dustin
October 5th, 2007 at 3:44 pm (#)
Hi Steve –
Welcome back to the blogoshpere! Great posts as usual.
I think you basically nailed it, but I tend to characterize things a bit differently. I completely agree the days of “one size fits all” are completely gone, and btw that’s why the concept of domain specific languages is so appealing.
I tend to think of the IT world as divided between systems designed before the Web, and those designed to include it. The mindsets are very different, as you point out, but I would add that the pre-Web mindset is kind of driven by mainframe centric designs – I like to think that the issues with existing middleware (and perhaps binary languages) is due to the fact we always felt we had to design in all the features/functions of mainframe based systems in order to entice enterprises to move those apps to standards based systems.
As you know the thinking behind the Web comes from an entirely diffent part of the software world. I believe the industry is starting to look at infrastructure behind the large Web sites as a kind of example of how things should be designed going forward. And I also think we are starting to see some software product designs based on these currently highly customized sites (this is the way a lot of the traditional middleware came to market too I believe, as vendors started productizing features/functions customers developed themselves when they couldn’t find products that met their requirements).
As you also say, it’s not possible to completely replace all the existing systems developed during the past 40 or so years of mainframe oriented thinking. I would suggest that implicit in your recommendation to do as much as possible based on HTTP is a recognition that we also need to build bridges into and out of these existing systems.
I did see at the end of your initial post this is your recommendation for when to use an ESB, so I am not arguing the point at all. Just trying to put a bit more emphasis on the idea that the corporate developers need help connecting up to the Web world.
October 9th, 2007 at 9:29 am (#)
[…] Vinoksy recently threw a lit match into the proverbial dynamite shack with his blog post, “The ESB Question“. Steve’s background and credentials (he was a very senior player at Iona) are […]