Join the DZone community and get the full member experience.
Join For FreeRoss from Mule has written an excellent blog entry on when an ESB makes sense. I think its very pragmatic advice.
The first point I want to make is that there is a huge difference between Open Source and Proprietary models here. Firstly, Open Source ESBs are usually pulled into projects rather than pushed onto projects. WSO2 certainly doesn't have salesmen taking people out for nice drinks and persuading them they have to have an ESB. This is a point that Ross makes very clearly and strikes a strong chord with me.
I've recently evaluated a project where I feel like the technology has been used because its there. Maybe its been used to justify the choice of an expensive software stack, but fundamentally the ESB had been thoroughly misused. In particular, there was not a single interface that could be used by more than one client or flow.
The second observation I have is about the ownership of the logic in the ESB, and the placement of function. The way that this ESB was developed was "monolithically". In other words a single team had the change management of the whole ESB, and the way it was run involved a multi-week long process to get even the most minor changes. This kind of model goes against the grain of an agile SOA and also makes the development teams struggle with the whole ESB model. By contrast we have a customer who has a model where changes can be (and actually are) made to the production system on a daily or even hourly basis, with zero downtime. This is on a system that handles peak loads equivalent to 85million messages/day.
We are working a lot on this issue of how to manage multiple concurrent ESB configurations and I think this will be a key improvement to the overall ESB approach.
The final comment I'd like to make about "to ESB or not" is that another thing we are often asked for is the ability to embed "ESB-like" function in a runtime. This is another good design pattern that can avoid problems: embed the transformation directly into the target system thereby simplifying point-to-point or even ESB-based architecture. This is exactly the model that Carbon allows, where mediation and transformation can be selectively added to Data Services, Business Processes, Service Hosting, etc.
The final point is about the responsibility of software suppliers to software users. Its always possible to misuse software. One of the very first experiences I had of ESBs was a large company building way too much business logic into their ESB layer and then beating up the supplier about it! In that case I think it was fair - the supplier had sat back watching the revenues come in and hadn't given the customer straight talk about how the product should best be used. This is the flip side of Open Source - we don't always get involved in the customer's solution until they are a long way down the path to production. But I'm always very straightforward - if I believe that the ESB is being misused or shouldn't be used, I'd rather lose the support revenue and gain the customer's trust by telling him or her straight.
The first point I want to make is that there is a huge difference between Open Source and Proprietary models here. Firstly, Open Source ESBs are usually pulled into projects rather than pushed onto projects. WSO2 certainly doesn't have salesmen taking people out for nice drinks and persuading them they have to have an ESB. This is a point that Ross makes very clearly and strikes a strong chord with me.
I've recently evaluated a project where I feel like the technology has been used because its there. Maybe its been used to justify the choice of an expensive software stack, but fundamentally the ESB had been thoroughly misused. In particular, there was not a single interface that could be used by more than one client or flow.
The second observation I have is about the ownership of the logic in the ESB, and the placement of function. The way that this ESB was developed was "monolithically". In other words a single team had the change management of the whole ESB, and the way it was run involved a multi-week long process to get even the most minor changes. This kind of model goes against the grain of an agile SOA and also makes the development teams struggle with the whole ESB model. By contrast we have a customer who has a model where changes can be (and actually are) made to the production system on a daily or even hourly basis, with zero downtime. This is on a system that handles peak loads equivalent to 85million messages/day.
We are working a lot on this issue of how to manage multiple concurrent ESB configurations and I think this will be a key improvement to the overall ESB approach.
The final comment I'd like to make about "to ESB or not" is that another thing we are often asked for is the ability to embed "ESB-like" function in a runtime. This is another good design pattern that can avoid problems: embed the transformation directly into the target system thereby simplifying point-to-point or even ESB-based architecture. This is exactly the model that Carbon allows, where mediation and transformation can be selectively added to Data Services, Business Processes, Service Hosting, etc.
The final point is about the responsibility of software suppliers to software users. Its always possible to misuse software. One of the very first experiences I had of ESBs was a large company building way too much business logic into their ESB layer and then beating up the supplier about it! In that case I think it was fair - the supplier had sat back watching the revenues come in and hadn't given the customer straight talk about how the product should best be used. This is the flip side of Open Source - we don't always get involved in the customer's solution until they are a long way down the path to production. But I'm always very straightforward - if I believe that the ESB is being misused or shouldn't be used, I'd rather lose the support revenue and gain the customer's trust by telling him or her straight.
Enterprise service bus
Open source
Published at DZone with permission of Paul Fremantle, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments