ESB Topology Alternatives
When adopting an SOA, it is now common to use an infrastructure such as an Enterprise Service Bus (ESB). There are, at least, two different ways of thinking about the infrastructure in an enterprise: use various ESB servers in the company, each solving a specific integration problem for a specific department, or use an ESB spread over the company, linking all parts of the Information System. This article discusses several architecture and management topics for the two different approaches.
For 5 years, ESB has been the buzzword for SOA foundation. This concept has been introduced by David Chappell, but today there is still no real definition. Indeed, each ESB vendor promotes its vision, and there are different approaches at the infrastructure level. Each approach has pros and cons.
A first approach is to let each department manages its SOA with its ESB implementation. It manages the integration of the application and the development of its business processes. By using separated and independent ESBs, each department is free to adopt the solution it wants. But when a communication with other partners is needed, it explicitly has to access or provide some business services by means of a standard "bridge" technology such as Web Services. In this case, the communication relies on protocols such as http, and quality of service like reliability or security has to be manually implemented.
A second way to see the SOA infrastructure is an overall view, where the ESB is unified throughout the company. The ESB spreads over the various servers of the departments, ensuring communication between them is possible. Calling a service from another department is done in an easy way, since the consumer contacts the ESB the same way that it does for a local service.
In this view, the ESB is really seen as a backbone infrastructure, like an Ethernet network. In more practical terms, the ESB is a set of natively inter-connected nodes; a node is a connecting point for services consumers or providers.
Note: An ESB node is in fact an ESB server that has internal network capabilities with other instances.
An ESB spread throughout a company network is not Big Brother
At first glance, a Chief Information Officer might say "Oh no, I don't want this kind of 'everywhere' tool that allows everybody to see and access everything in the company", administrators might claim "What can I manage or supervise?", "Other administrators can change things on my servers, this is not possible", or the well-known "What about security?", and so on...
Obviously, a generalized ESB does not allow everything. It just simplifies communication over the network and offers a set of quality of services throughout the network, in a simplified way.
Domains in a unified ESB
Domains and sub-domains define borders between entities. Thus, from an administrative point of view, each "node" of the ESB is only manageable by the sub-domain administrator. He or she is the only person that can start, stop, install connectors, deploy services and so on. The administrator manages the ports used by the ESB nodes of his domain and can set proxies or firewalls to protect these ports.
A business service deployed on the node of a domain can be public or private. That is to say, a private service is only visible, in the registry, by consumers which are in the same domain. Moreover, the private service is only accessible for the same domain consumers.
Note: These private services will not being discussed in the following sections, unless specified otherwise.
The service and process monitoring can only display information of the domain or public information of the others' domains. It is not possible to see other private domain processes or service statistics.
Now that we have cleaned up any potential misunderstandings about what a unified ESB is, let's take a look at some of its advantages.
In a disconnected ESB environment, a service from another domain exists only if a bridge is explicitly created for this service between the two domains' ESBs. For example, a service from one domain is exported as a classic Web Service and another ESB has to know the URL to call it. A company-wide registry is needed to reference all these Web Services. In this case, administrators of each domain have to publish the domain's Web Services to this company registry. These Web Services can be considered as the "public" services of the company, as they are visible by all.
In a unified ESB, the business services registry is itself unified; the registry of each ESB instance is synchronized with the other ones. A consumer or a service browser that connects to an ESB in a domain can see all the services on the bus. When a new service is exposed on the ESB, it is immediately seen and accessible for every consumer on each ESB instance, despite its physical localisation. All services are accessible in the same way; they are "ESB services". No matter their implementation or their protocol.
To orchestrate services spread over multiple disconnected ESBs, there are two ways of conceptualizing the orchestration. First, the BPEL engine is exterior to the ESB environment, for example it could be a Web Services BPEL engine. In this way, the process designer needs to know all the services across the domains. It would be also necessary to integrate these services as Web Services to access them. At runtime, the BPEL engine has to make some http connections over the global network to access services.
On the other hand, the BPEL engine could also be integrated in an ESB, calling services that are available in the local environment. When it has to access a service which is on another ESB, a bridge (like a Web Service call) must be employed to access the other ESB and then the service.
With a unified ESB, the "internal" registry contains all the services of the bus and their description. It is easy to design processes by connecting the BPEL designer to the ESB registry. The design of the process only deals with the ESB services. All the available services can be retrieved from the unified registry and directly integrated into the process. At runtime, transaction or compensation problems are easier to take into account as there are no bridges between the BPEL engine and the services.
In an integration environment like a SOA, there is, in essence, a lot of communication between applications. They are spread over different servers and information is largely conveyed through the network. The transport layer of the infrastructure needs to be as strong as possible to avoid information loss. The ESB transport layer often offers message reliability, but the bridge between the ESB and the application relies on the protocol capabilities (such as Web Service, FTP, JMS, RMI ...).
With disconnected ESB instances, the reliability needs to be ensured between instances too. For each service located on another ESB instance, a reliable communication has to be configured. A JMS Queue per service can be used to do so. In addition, the communication between the sender ESB, the JMS Queue and the receiver ESB might need to be transactional. The work becomes hard when there are a lot of other domains' services to access.
Using a unified ESB allows installing one ESB instance on each physical server that hosts an application to integrate. In this case, a Web Service call or an FTP connection still remains on the server. A network breakdown will not affect the communication between the application and the ESB node. The network communication is achieved by the ESB nodes. The reliability is guarantee by the transport layer of the nodes (generally based on a JMS MOM).
Of course, installing an ESB node on each server hosting an application is an ideal vision. Applications that do not need a perfect reliability can connect to a distant ESB node hosted on a separate server; as well in a network safe environment, ESB servers might also be shared by several applications. It depends on administrator resources, costs,...
Managing services lifecycle or versions is not easy in a disconnected environment. When a new service is exposed in an ESB instance, connectors have to be configured to expose it to other instances in order to allow consumers from other instances to access it. When a new version of this service becomes available, each connector has to be updated to be consistent with this new version. Moreover, if there is no company-wide registry that references all ESB instances services, consumers from other ESB instances will never know that some services exists on an instance.
In a unified ESB, as each instance is natively interconnected, a service which is deployed on an instance is immediately available on the other ones. This service is visible in the registry of each instance. When this service changes, each consumer has benefits from this new version.
Most of the time, the administrator of a disconnected ESB environment (who is performing connector installation, service deployment and other lifecycle management) has to connect to each ESB administrative console of the domain. The administrator configures the ESB instances behaviours separately.
Using a unified ESB allows the administrator of the domain to manage all the nodes (of the domain) in a single administrative console where he looks at all the topology. The main benefit is that the administrator watches all instance activity (resource consumption, service call statistics...) and can manage the behavior of the ESB in the domain. For instance, if a service, such as an XSL transformation, is heavily used, the administrator can instantiate a copy of this transformation service, deploy it to another instance, and define a load balancing rule to dispatch the requests. Such capabilities can not (or only with difficulty) be done in a disconnected ESB environment.
Business activity monitoring is one of the most interesting features that an SOA infrastructure gives to operations managers. Service statistics are available in real time; business processes are monitored and can be optimized, alerts can be thrown by emails when anomalies occur...
With disconnected ESB instances, gathering key performance indicators (KPIs) is not easy. KPIs from each ESB instance have to be collected separately and the communication between two instances (a Web Service call for instance) is not easy to monitor. All the data has to be correlated before being readable by the monitoring tool.
Once again, a unified ESB simplify the KPI collection through the domain. As there is no protocol break between instances, the lifecycle of an exchange can be monitored from the consumer to the service provider even if they are not hosted by the same ESB instance. The monitoring console connects to any instance of the domain and can display the domain statistics.
Each ESB offers its set of functionalities and tools to integrate applications. With a set of connectors and services like transformation or orchestration, applications integration has become easy.
For a given integration problem, one can use a "centric" ESB, some connectors and use it to build the glue between 2 or 3 applications. This "point-to-point" approach is easy and quick to set up, and does not require business service definition (WSDL and other) most of the time. As we have seen in this article, this "integration" view might be sufficient for such a simple case, but is not enough in a real "Services Platform" approach, where the ESB has to be the SOA backbone of the enterprise.
Choosing an ESB implementation that allows a real network communication is a major key for a "Service Platform" infrastructure adoption in the enterprise. It allows a global view of all the activity and business of the Information System and enhances its agility, as every service in the whole enterprise can be easily used, in a business approach way.
About the author
Adrien Louis works as chief architect at EBM WebSourcing, and has 8 years of experience working with Java EE technologies. Currently, he is working on enterprise integration solution problems. Adrien is an SOA consultant and the architect of the PEtALS open source project. PEtALS provides a leading open source ESB to support SOA and aims to be a lightweight, highly distributed and scalable platform for both A2A and B2B integration. Thanks to its specific distributed architecture and the tools provided, PEtALS offers a very competitive integration solution with support of a large number of protocols, formats and integration features.
Nodes can carry their own intelligence, in a P2P kind of way. We have DNS for name resolution, and I question the whole concept of semantically challenged associative service registries.
ESB may be a useful logical concept, but as a physical piece of infrastructure it creates friction, and is an excuse to avoid fixing the problem with a giant cash-sucking band-aid. Just like EAI was. Sorry :).
Re: or.....no ESB
Disclaimer, I am one of the co-founder of EBM WebSourcing and the company CTO :-).
ESB may be a useful logical concept, but as a physical piece of infrastructure it creates friction, and is an excuse to avoid fixing the problem with a giant cash-sucking band-aid.
Either you use a middleware to deal with all the non functional aspects of SOA (SAL, Security, ...), or you have to explicitly manage all these non functional aspects. I think that using such a middleware to create a SOA is very useful, and that's what I call an ESB.
Furthermore, AFAIK, even if EAI failed, integration issues are still very important in Information Systems and we still have to integrate applications implemented with heterogeneous technologies, protocols and formats. A pragmatic SOA approach based on an ESB like PEtALS enables such an integration layer.
Last, the fact is that integration issues are never fixed inside the applications, and that's why open source ESB like PEtALS help fixing it at a reasonable TCO.
Nodes can carry their own intelligence, in a P2P kind of way.
That's exactly the type of architecture you can implement with a unified ESB as described in this article. And that's what we develop since the inception of the project : a distributed ESB, with unified monitoring and management. Thus, each node can be deployed the nearest as possible to the application to integrate, and can even be embedded into the application server.
Re: or.....no ESB
Why do you need bridges?
Re: Why do you need bridges?
Re: Why do you need bridges?
i guess that's because each legacy have their own unique way of communicating with 'their own ESB'. And you want to keep it that ways because you want to shield that that complexity away from other division. Example ESB2 is build to server Divison B and have a unique protocol. You don't want ESB1 to create another service point for Div B because ESB1 shouldn't care about servers in Div B, that's ESB2 job. Correct me if i'm wrong.
In the separate ESBs scenario, if ESBs are within the enterprise's network, why do you need bridges from one to another? Why can't a service consumer simply call a service exposed on any ESB directly?
Of course it is possible, but sometimes the need for a 'bridge' depends on non-functional requirements that differ for both ESBs.
E.g. security requirements. A bridge would allow you to add additional authentication and authorization to access of services on ESB2 from the ESB1. It even makes it possible to let the final access to the service on ESB2 be done using credentials that are only known in ESB2, but authentication/authorization on the bridge can be based on credentials of ESB1 clients.
Have a look at this presentation about WSO2 Identity Server (especially slide 59, 60 and 62). It might help understand the need for bridging in case of the above mentioned security requirements.
By the way, personally I would not use the term 'bridge'. I rather use the term 'proxy' or 'proxy service'. But then again, I might have misinterpreted 'bridge'.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015