The role of the ESB in the SOA strategy
You may have heard of the ESB acronym. In the ICT sector, we are very fond of acronyms, as everyone knows. So a few more acronyms … but here we are talking about an important one. The ESB plays a fundamental role in an SOA strategy and in the transformation of an information ecosystem.
So far we have tried to make clear what SOA really is and the tremendous value it has as a strategy for an organization, both operationally (agility, scalability, competitiveness), and from the economic point of view (significant reduction of Costs).
However we have hardly commented anything about its technological aspect, which also has it. We have strongly insisted on separating it from technology, in the sense of not relying on any fashion paradigm, no framework, no platform, no ICT provider. The SOA strategy does not need to be rethought in the face of technological changes of any kind because its main focus is on governance.
Even so, the implementation of an SOA strategy requires a specific specialized infrastructure, which allows the publication of the SOA Services Catalog and the management of that catalog, defined policies, etc.
In the two previous posts we have used real-world examples to show how the basic principles of SOA surround us much more than we think, and SOA is actually a logical and necessary evolutionary leap in the history of ICT. Both examples included a central infrastructure, equipped with the ability to receive information from any component meeting standard specifications, and to send information to the corresponding components according to certain rules. In the first example that infrastructure was the high-end amplifier. In the second example, that infrastructure was the central nervous system.
Well, analogies aside, the protagonist we alluded to was the ESB (Enterprise Service Bus).
Basically it is a hardware and software solution that constitutes the backbone of the organization’s systems map under an SOA strategy.
The functions of the ESB are varied and all very important:
Often organizations acquire an ESB and only use it as a router, little more, unfortunately. And sometimes there are those who believe that having an ESB, already has SOA. If you have followed my previous entries you will easily see how wrong this belief is.
There are quite a few ESBs on the market, including open source. The leading enterprise software vendors in the industry have their ESB. Here we will not stand out against each other, but we will list the characteristics that should ideally have an ESB:
In addition to these features, it is necessary to have a viewer or console to manage the status of services, queues, retries, messages, etc., etc.
Apart from the purely technical functions of the ESB, its role within an SOA strategy is very important from the strategic point of view. As important to the organization as our own spinal cord is to our body.
Visually, after the implementation of the ESB versus the same systems map prior to ESB implementation the systems map is quite impressive. It brings decoupling, order, coordination, a vehicle to implement governance policies, a security barrier, a valuable monitoring point (not in vain by the ESB circulates each business event, its associated message, date and time), and a constant provider of information, events and services under well-defined standards.
With an SOA strategy, all information systems stop looking at each other, disoriented looking for the information they need, and have two clear references:
- Functional reference, with the SOA Services Catalog where they can identify the services to be subscribed to as consumers, or the services they provide as suppliers
- Technological reference, with the ESB, where these SOA services come alive publishing the components that are invoked by the vendor systems and managing the subscription lists of each service to invoke the consumer systems.
To summarize: as we have been saying throughout the previous posts, the SOA strategy is independent of the technology. This independence has two aspects:
The ESB is the backbone of the systems map in an SOA strategy, the nerve center where:
– the policies defined from the governance are implemented,
– the SOA services catalog is published for reuse,
– the business events and their associated processes are orchestrated,
– business activity is monitored
We will talk about the ESB in future entries. After all, it is the most tangible part of the SOA strategy, especially for the information systems that connect to it.