|Service Oriented Architecture (SOA)|
|Services vs. Applications|
|Enterprise Service Bus (ESB)|
An "Enterprise Service Bus" (ESB) is a system to which all services are connected. Through the enterprise service bus all connected services can also be accessed. Here is an illustration of an enterprise service bus which acts as central "bridge" or "gateway" to all applications exposing services underneath it:
Here is a list of the topics covered in this text:
The term "bus" is an analogy to the internal bus of a computer onto which the CPU, RAM and other chips are connected. An enterprise service bus is typically implemented as a server or a set of servers, and is thus more than just a "network".
|An enterprise service bus with applications (services) connected|
Clients and services connected to an enterprise service bus do not communicate directly. They communicate via the ESB. This is done by having the ESB essentially expose the same service interface to potential clients, that the connected services expose to the ESB. This indirection via the ESB has some advantages and disadvantages, which I will cover in the rest of this text.
One advantage of connecting clients and services via an enterprise service bus is that clients need only look for services in a single location: The enterprise service bus. If a service is moved from one server to another, you only need to reconfigure the ESB. The clients still just access the service via the ESB.
Another advantage is that the ESB can coordinate distributed transactions which multiple services participate in. When multiple distributed services need to participate in a transaction some entity typically has to coordinate the transaction. Rather than forcing the client to do this, the enterprise service bus can do so. The client may still have to demarcate the beginning and end of the transaction, even if the work of coordinating the participants is done by the ESB.
|An enterprise service bus (ESB) managing a transaction spanning three services|
Security aspects like authentication and authorization can be centralized in the enterprise service bus. Even if a service in an application does not have authentication and authorization, the enterprise service bus can require this in the service interface it exposes to potential clients.
|An enterprise service bus (ESB) authenticating and authorizing the client before forwarding service requests to services.|
An ESB may function as a gateway or proxy for appliations that do not expose a standardized service interface to the world. For instance, lets say an application exposes a Java RMI service. The rest of your network is running on .NET which cannot directly call the RMI service.
To solve this problem you can implement a service proxy in Java which can call the RMI service. The service proxy then exposes a web service interface (SOAP + WSDL) via the ESB to the .NET applications.
Such a proxy service does not have to be a built-in capability of an ESB. It can also just be deployed as a separate service, made available via the ESB.
|An enterprise service bus (ESB) as service proxy for a service with a proprietary protocol.|
If some clients need to connect to services running in the outside world, the ESB can potentially function as a gateway to the world outside. Again, security aspects etc. can be added ontop of the external service. Furthermore, if the external service is capable of participating in distributed transactions, the ESB can coordinate this too.
|An enterprise service bus (ESB) as gateway to the world.|
Connecting your services via an ESB also has a few disadvantages. First of all the ESB may become a single point of failure. If the ESB is down, no communication between clients and services can take place. Second, the extra level of indirection may result in decreased performance of client-service communication.