ESBs vs. Smart Routers
I went to a great presentation by Paul Fremantle about building an ESB using Synapse. Paul is a co-founder of and VP at WSO2 and very sharp. He did a great job distilling down the key pieces of Synapse and what it looks like to define service endpoints and do transformations. Synapse deals in various messaging formats like a good ESB, but made the interesting decision to internally treat everything as a SOAP message. If you make a REST call into the ESB, it internally gets wrapped as a SOAP message so you can add headers, reply tos, etc. Probably makes for a more sane server-side model.
But an audience member at the end asked what I consider to be a very prescient question about overlap with capabilities that are continually being added to routers - things like content based routing and filtering. Depending on who you talk to, BPM is supposed to be handled outside the ESB and the ESB should focus on lower level services like routing, filtering, and transformation. I can't help but think that ESBs are hot for that right now mainly because it's much easier to innovate and collaborate in the software domain. It seems to me that ESBs are almost commodity out of the gates, and these needs will ultimately be met in the firmware/hardware domain.
Could smarter routers just end up being the deployment node for more elaborate ESB-like routing and filtering logic? Will ESBs (if they are limited to that low level) survive much longer when the hardware can ultimately do it faster?
posted by scott @ 7:22 PM
6 Comments:
To be honest I'm not completely sold yet on the hardware model. I not against it, I'm just not sold. I know from speaking with Anne Thomas Manes over at the Burton Group that she seems to be a big fan of the XML appliance. There are a lot of potential positives as pointed out.
I think on the downside there are probably slower release cycles, difficulty in distributing your environment to endpoints, clash of cultures (Network versus Software), and potential to get very locked in via the hardware.
I also believe that legacy integration is a very important part of this. This type of integration requires a lot of heavy lifting that the network vendors simply don't have experience with.
Maybe the best fit for these hardware devices is as a simple Intermediary doing content based routing, maybe some policy enforcement etc. Although putting this type of logic in the switch makes me a bit nervous. I may still come around but right now it's proceed with caution.
Mark -
All very good points. I'm admittedly more of a software guy than a hardware guy, but that idea just took root in me a little during that presentation.
Just like firewalls today do a certain low level of access control policy enforcement, I could see smarter routers taking on some of those lower level routing jobs instead of middleware.
And like you say legacy integration is key and that will tip the balance in favor of software. I also don't think everyone wants to or does a good job separating policy enforcement into layers (this goes on the router, this goes in the ESB, etc.) so it will probably just be easier to do it all in the ESB.
But I like the just another deployment node concept - maybe we will see partnerships so that from a single UI, ESB configrations can get deployed to different network nodes (some rules go to the router, some go to the ESB platform).
Thanks for your comment, great thoughts.
One of my favorite subjects! I am a self-admitted fan of smart routers, as you call them. There are two keys to this debate and deciding what's best for the organizaiton, as I see it. I gave a presentation on this at Burton Group's Catalyst conference in San Francisco in 2006.
First, you need to have some idea of what capabilities you want "in the middle." You brought up the debate around whether BPM belongs in hte ESB. I'd rephrase that as whether orchestration belongs in the middle or not. I don't think it does. An orchestration engine will be the recipient of service requests and events, and will certainly initiate many service requests. To me, it's an endpoint, not an intermediary. That's an opinion, however, there's no hard and fast rules. More debatable capabilities include adapter-based integration ala EAI, queueing capabilities ala MOM, and transformations.
The second thing to consider is who will be provisioning the service policies after the product is installed. Do you want a deployment team using Eclipse? Do you want a network or security operations team using Eclipse? Do you want a development team to go through some web-based console? I don't think the debate should be about the classic hardware performance versus software performance. It's more about ease of use and fit into the enterprise. A hardware appliance will likely be easier to manage than a software device. Of course, if you have to use a Cisco IOS interface to configure web service policies, that would be bad, so user interface has to come into play.
In short, I think if you nail down the capabilities, eliminating the grey area in integration and transformation, and have a clear idea of who in the organization will use the system, the product space should be clear.
Todd -
Those are all great points. In particular, I think you are right about the tooling and separation of responsibilities.
For all of the people talking about SOA and ESBs here, there seems to be general agreement that orchestration does not belong in the hub.
Great discussion...
I am an architect at a Fortune 100 company.
I am sold on the idea of appliance replacing some of the features that is usually accomplished by ESB.
Specifically, I believe software based solution like ESB would be good for
* adapters for legacy integration (EAI type)
* MOM functionality
* Transformation that need custom message format (fixed length etc)
As for orchestration, I believe it is an endpoint service (a business service) and not a functionality of the middle guy.
In short after seeing the SOA and XML growth, I would prefer to have a much simple, cost effective, performance solution like appliance rather than container based solution built on general purpose app server.
But certainly as you all have mentioned, appliance do disrupt the existing organization structure. I would like to have a appliance that application developers can work on....to minimize the impact to an organization structure.
Nice points about the ESBs & smart routers...
Post a Comment
Trackbacks
<< Home