Today, I would like to say just a few words on ESB´s. As you may know, I´m a Java developer, but I work specifically with SOA (Service-Oriented Architectures) and Service-Oriented Computing in general. So, my day-by-day tools include not only those of Java, but some known as belonging to SOA stack, like BPM, BPEL and ESB.
ESB is an acronym for Enterprise Service Bus. It is a tool designed to provide flexibility to SOA, and refers often to the Message Broker pattern. It´s use often provides flexibility to SOA, but, indeed, adds more complexity to the overall architecture.
Generally, an ESB must provide or enhance the following features:
- Services virtualization
- Services security
- Services management
- Services availability
- (other) SOA Messaging Patterns
- WS-* specs support
To be succeeded on its intent, the Enterprise Service Bus must have the ability to “hide” the underlying services. Such capability is achived by deploying services on the very own ESB, with abstract service contracts, or by “hiding” them, providing a new service contract and then routing messages to the underlying implementation. This capability is very important because by doing so, the ESB can:
- Re-route messages (for example, if a service is not available, it may call another one instead)
- Add security and SLA (Service Level Agreements) layers
- Group (or split) service capabilities from (or to) several different service contracts
- Hide informations on implementations (for example, suppose that that we don´t want the client to know that the underlying implementation is a JMS service – yes, it can be one!)
- And the main purpose: provide service decoupling
The last quoted capability is so important that it deserves its own explanation: the structure of a concrete service contract includes a section where the service address is specified. But, suppose that I can not guarantee that this address will always be the same. If this service address changes, all clients will be impacted, and, for sure, that is not what we expect when implementing SOA. Also, suppose that a service model changes (which, of course, is highly undesirable if someone wants to succeed when adopting SOA, but it may happen in the real world). The ESB may completely override service contracts, routing messages to the real implementation and even transforming messages so the can be compliant to the real implementation (just a note here: transformations, in SOA, are very undesirable as they decrease the system performance, but, still, they may be neccessary).
Suppose that you want a given service to be secure. This service needs muthual authentication through certificates, but still, it needs to be very, very, very (very!) fast, as you cannot tolerate it to delay too much. Now, consider that this same service is going to be consumed both from the inside of your application (still being used as a service) and from outside. The outside requests must be handled in a secure way in opposite to the inside ones. Then, you can place the whole security stuff in the ESB, as it does the rest. This approach has a bonus, which is that you are sppliting processing need through layers and machines, as the ESB machine processes the security layer and the service layer machine processes the logic itself (along with some XML parsing, for both of them).
Well, services management is pretty wide term, but as far as I concern, the main pieces that an ESB provides in this sense are:
- Services “split” capability
- Services “regroup” capability (in oppose to the previous topic)
- message filtering
- add SLA capabilities
So, the “split” and “regroup” has been mentioned in the topic of services virtualization, as the ability to “rewrite” service contracts. Message filtering is in the sense that, generally, the ESB transcends the web services capabilities and that it can filter messages. A practical example of this filtering is that, suppose that you set in place a query service and that a malicious user place a query that intends to cause overflow on the server, making it to crash. The ESB can cut off the request and/or the response, limiting, for example, the size of the message, allowing to pass only messages below 8 megabytes.
An ESB can enable high availability / load balancing capabilities for web services, increasing the failure recovery hability of the SOA application. Just in case you ask: this is an example of why one of the services design principles is to make statelss services. So, if any of you ask me how to make a stateful service, it is more likely that I answer you something like “you don´t need this” rather than “do x, y, and z”.
SOA Messaging Patterns
There are lots of SOA (and Enterprise Integration in general) patterns that an ESB implements. I would be here for at least a couple of hours writing about them, but I would be repeating what is already catalogued, and you can check these patterns at SOAPatterns.org website.
WS-* specs support
A good ESB must comply with a few standards, as this is one of the major goals of SOA. The WS-* specs are a couple of specs to address some common issues related to web services, like distributed transactions (WS-Transaction), dynamic addressing (WS-Addressing) and security (WS-Security), just to mention a few. You can check a more complete list of specifications here.
So, what am I waiting for? I want to use an ESB!!
Hold on. There are lots and lots of discussions on whether it is good or not to place an ESB over a SOA architecture, and how far the benefits go and how far the headaches go. I would only be awakening the flame war of “to ESB or not to ESB” by exposing my opinion here, so I would like to keep it for myself. If you want to check it for yourself, have a look at this google query.