The ESB and the SOA
(I am replacing this post, because the original one was too obscure and not even me really understood it after some time of having written it. So I hope the new version transmits better which I think has to be the role of an ESB in a SOA.)
ESBs are, for one thing, a fuzzy category of middleware products with a large variety of capabilities. From these capabilities, I think there are two that ESBs are well suited to perform:
ESB products usually perform other capabilities like monitoring, security, logging or endpoint management. These other capabilities are useful only if the ESB mediates in every consumer-service interaction, because otherwise you need also of additional mechanisms different than the ESB.
This is the other meaning of the word ESB: an architectural pattern in which the SOA has three main type of elements: services, service consumers, and the ESB, which is an element independent from the other two and which is the neccessary mediator in any interaction between the other two. To me, to call a product an ESB it must allow to implement this pattern, and this is why I do not see the IONA middleware, which is agent-based and not an independent element, as an ESB.
I think the ESB pattern makes sense in some kind of SOAs (more on that later), but I consider that saying that every SOA has to follow this pattern is plainly wrong. A Service-Oriented Architecture is a way to structure an IT system so that as most logic as possible is implemented in services which can be freely consumed by any other element of the SOA, as long as it knows the service description (mainly, its interface). This vision does not need a intermediate element like an ESB to make these interaction possible, and thus requiring it is just misleading.
As I said, to use an ESB to implement the latter capabilities requires not only the ESB product but also to follow the ESB pattern, but not every SOA has to implement this pattern. If your architecture follows the ESB pattern you can well use the ESB to implement these, but your architecture may not follow that pattern, and thus an ESB would not be useful to implement these capabilities and you will have to use other solution to implement them. However, for the two first capabilities (communications and orchestration), an ESB may be useful in any kind of SOA.
So I am not against the ESB product per se, but more against the ESB pattern being mandatory. I think the ESB pattern makes sense in some cases, but it is not the only way of doing SOAs. Indeed, for many SOAs it is a wrong pattern.
The ESB pattern is actually an integration pattern. The more diverse sources to integrate you have, and the simpler they are, the more useful is the ESB pattern. The extreme ESB pattern requires very basic services which are fully decoupled, i.e. which are never consumers of other service. Then, you integrate them using the ESB, and after that you can have other consumers leveraging the integrated set. Of course, this happens to be the same as the EAI pattern, in which you have existing systems you want to integrate. This is not casual, because ESB products are actually an evolution of EAIs.
But, while an EAI is a solution for integration and only for integration, SOAs are more than this. For example, if you do not have existing systems to integrate (e.g. a new distributed system is created from scratch), an EAI product would be useless. But a SOA would still make full sense, because SOA is just a way to structure functionality inside of a IT system by means of services.
This is a common mistake: many people think that the main value, even the only value of SOA is integration. This is wrong. SOA is more than that. Of course services are a good way to expose the functionality of systems to be integrated, but this is not the only usefulness of services. Besides integration, services are useful as a mean to split functionality in bits and then reuse it.
These people sees Service-Oriented Architecture as an integration architecture, and this is why they see that the only way to create a SOA is by means of the ESB pattern. But this is one flavor of SOA, not all of SOA.
Thus, I see ESBs as a good means to implement managed communications and orchestration when you need them, which is often. This is, if the interaction between consumer A and service B needs managed communications, it is OK to put an ESB in the middle. If you have three services C, D and E and they are often used jointly in a coordinated way, it is perfectly good to use an ESB to create service F which would orchestrate them. If you have service G with an interface but you have consumer H which expects another interface, is is fine to use an ESB to implement H's interface and transform it into G's interface. And so on. Of course you can use also other methods than ESB for that, but ESBs are just fine.
But if you want to log all the messages going through your SOA, or enforce security polices for consumers and services, or monitor activity, or be able to change the location of your services without broking the SOA, an ESB is useful only if you follow the ESB pattern, which may well not suite your SOA. If you have an integration-intensive SOA it may be the best option to follow, but otherwise it is better you look for other ways of implementing these, because it could be negative to force your SOA to follow the ESB pattern.
The bottom line: I see perfectly sound to use an ESB to implement managed communications and orchestration in any kind of SOA. But for other capabilities like monitoring or security, unless the ESB pattern suites your SOA I would rather recommend using other kind of solution, like agent-based middleware or just SOA communication libraries. The more integration needs you have, the more useful is an ESB to implement your SOA.
I think the ESB frenzy is temporary and that eventually everybody will see things this way. But there has been people saying similar things since 2004, and still the ESB is commonly presented as the king of the SOA. However, the implementation of larger and more complex SOAs, and the growing importance of governance and registries and its usage at runtime, may displace the focus from the ESB and change this perception.
ESBs are, for one thing, a fuzzy category of middleware products with a large variety of capabilities. From these capabilities, I think there are two that ESBs are well suited to perform:
- Managed communications, including support for different protocols, asynchronous and publish/subscribe communications, and reliable communications (in general, anything that is not supported by the communication stacks available in the consumers or the services).
- Orchestration, which includes message routing, transformation, aggregation and creation of composite services.
ESB products usually perform other capabilities like monitoring, security, logging or endpoint management. These other capabilities are useful only if the ESB mediates in every consumer-service interaction, because otherwise you need also of additional mechanisms different than the ESB.
This is the other meaning of the word ESB: an architectural pattern in which the SOA has three main type of elements: services, service consumers, and the ESB, which is an element independent from the other two and which is the neccessary mediator in any interaction between the other two. To me, to call a product an ESB it must allow to implement this pattern, and this is why I do not see the IONA middleware, which is agent-based and not an independent element, as an ESB.
I think the ESB pattern makes sense in some kind of SOAs (more on that later), but I consider that saying that every SOA has to follow this pattern is plainly wrong. A Service-Oriented Architecture is a way to structure an IT system so that as most logic as possible is implemented in services which can be freely consumed by any other element of the SOA, as long as it knows the service description (mainly, its interface). This vision does not need a intermediate element like an ESB to make these interaction possible, and thus requiring it is just misleading.
As I said, to use an ESB to implement the latter capabilities requires not only the ESB product but also to follow the ESB pattern, but not every SOA has to implement this pattern. If your architecture follows the ESB pattern you can well use the ESB to implement these, but your architecture may not follow that pattern, and thus an ESB would not be useful to implement these capabilities and you will have to use other solution to implement them. However, for the two first capabilities (communications and orchestration), an ESB may be useful in any kind of SOA.
So I am not against the ESB product per se, but more against the ESB pattern being mandatory. I think the ESB pattern makes sense in some cases, but it is not the only way of doing SOAs. Indeed, for many SOAs it is a wrong pattern.
The ESB pattern is actually an integration pattern. The more diverse sources to integrate you have, and the simpler they are, the more useful is the ESB pattern. The extreme ESB pattern requires very basic services which are fully decoupled, i.e. which are never consumers of other service. Then, you integrate them using the ESB, and after that you can have other consumers leveraging the integrated set. Of course, this happens to be the same as the EAI pattern, in which you have existing systems you want to integrate. This is not casual, because ESB products are actually an evolution of EAIs.
But, while an EAI is a solution for integration and only for integration, SOAs are more than this. For example, if you do not have existing systems to integrate (e.g. a new distributed system is created from scratch), an EAI product would be useless. But a SOA would still make full sense, because SOA is just a way to structure functionality inside of a IT system by means of services.
This is a common mistake: many people think that the main value, even the only value of SOA is integration. This is wrong. SOA is more than that. Of course services are a good way to expose the functionality of systems to be integrated, but this is not the only usefulness of services. Besides integration, services are useful as a mean to split functionality in bits and then reuse it.
These people sees Service-Oriented Architecture as an integration architecture, and this is why they see that the only way to create a SOA is by means of the ESB pattern. But this is one flavor of SOA, not all of SOA.
Thus, I see ESBs as a good means to implement managed communications and orchestration when you need them, which is often. This is, if the interaction between consumer A and service B needs managed communications, it is OK to put an ESB in the middle. If you have three services C, D and E and they are often used jointly in a coordinated way, it is perfectly good to use an ESB to create service F which would orchestrate them. If you have service G with an interface but you have consumer H which expects another interface, is is fine to use an ESB to implement H's interface and transform it into G's interface. And so on. Of course you can use also other methods than ESB for that, but ESBs are just fine.
But if you want to log all the messages going through your SOA, or enforce security polices for consumers and services, or monitor activity, or be able to change the location of your services without broking the SOA, an ESB is useful only if you follow the ESB pattern, which may well not suite your SOA. If you have an integration-intensive SOA it may be the best option to follow, but otherwise it is better you look for other ways of implementing these, because it could be negative to force your SOA to follow the ESB pattern.
The bottom line: I see perfectly sound to use an ESB to implement managed communications and orchestration in any kind of SOA. But for other capabilities like monitoring or security, unless the ESB pattern suites your SOA I would rather recommend using other kind of solution, like agent-based middleware or just SOA communication libraries. The more integration needs you have, the more useful is an ESB to implement your SOA.
I think the ESB frenzy is temporary and that eventually everybody will see things this way. But there has been people saying similar things since 2004, and still the ESB is commonly presented as the king of the SOA. However, the implementation of larger and more complex SOAs, and the growing importance of governance and registries and its usage at runtime, may displace the focus from the ESB and change this perception.
Labels: soa ESB
posted by Javier Cámara at 4:55 AM
(Permalink)
0 Comments:
Post a Comment
<< Home