ESB is another of these amorphous terms that means different things to different people.
An ESB can be thought of as the next generation of Service Oriented Architecture. Everybody knows web services today, and they have been used extensively to allow companies to break the tyranny of proprietary architectures. Now you can wire applications to service providers without having to know or worry about the provider's underlying operating system or programming language.
It is an architectural concept/construct - not a technology, despite some vendors (and even gartner) telling you otherwise. You'll find many different types of technology can fulfil the conceptual role of an ESB, hence be careful not to associate it with a particular technology. Therefore designing the architecture is more important than choosing a 'product'.
An Enterprise Service Bus (ESB) is the "backbone" of the service-oriented architectural model which allows different protocols to be communicated throughout the organisation. With the onset of many different protocols for sharing information for web services, aggregation, remote calls etc. there were a range of different protocols invented to handle these. Protocols such as SOAP, REST, xmlrpc, JMS, RSS, atom and the list goes on. These and more standard protocols such as smtp, nntp etc can all be managed for easier communication between endpoints by the ESB. Think of it as a "protocol translator" for your service-oriented architecture.
Enter the ESB. With the use of an Enterprise Services Bus, the service providers now advertise their services with the bus. "Here is a GeoCoding service", "Here is a service for posting transactions to the General Ledger" and so on. Now when a service wants to post to the GL, it will subscribe to the service by its identity and not its location (where identity is something like "accounting.gl.posting").
Obviously this breaks you of the tyranny of dealing with large numbers of web services that all talk to each other. It provides you a central common point for dealing with security, providing transactional support and guaranteed delivery instead of dealing with multiple different ways of doing these things.
Network Administrators also get one dashboard to view traffic between service providers and subscribers, instead of a mix of in-house developed and third party solutions.
An ESB can be thought of as the next generation of Service Oriented Architecture. Everybody knows web services today, and they have been used extensively to allow companies to break the tyranny of proprietary architectures. Now you can wire applications to service providers without having to know or worry about the provider's underlying operating system or programming language.
It is an architectural concept/construct - not a technology, despite some vendors (and even gartner) telling you otherwise. You'll find many different types of technology can fulfil the conceptual role of an ESB, hence be careful not to associate it with a particular technology. Therefore designing the architecture is more important than choosing a 'product'.
An Enterprise Service Bus (ESB) is the "backbone" of the service-oriented architectural model which allows different protocols to be communicated throughout the organisation. With the onset of many different protocols for sharing information for web services, aggregation, remote calls etc. there were a range of different protocols invented to handle these. Protocols such as SOAP, REST, xmlrpc, JMS, RSS, atom and the list goes on. These and more standard protocols such as smtp, nntp etc can all be managed for easier communication between endpoints by the ESB. Think of it as a "protocol translator" for your service-oriented architecture.
Enter the ESB. With the use of an Enterprise Services Bus, the service providers now advertise their services with the bus. "Here is a GeoCoding service", "Here is a service for posting transactions to the General Ledger" and so on. Now when a service wants to post to the GL, it will subscribe to the service by its identity and not its location (where identity is something like "accounting.gl.posting").
Obviously this breaks you of the tyranny of dealing with large numbers of web services that all talk to each other. It provides you a central common point for dealing with security, providing transactional support and guaranteed delivery instead of dealing with multiple different ways of doing these things.
Network Administrators also get one dashboard to view traffic between service providers and subscribers, instead of a mix of in-house developed and third party solutions.
And at the end of the day, this is where an ESB will save you money. It does not generate money in and of itself, but it greatly improves developer productivity, shortens development cycles and greatly simplifies the maintence of the application in production. As I said right at the start, the ROI depends on how much pain you are feeling with SOA today in a complex environment.
The picture shows how ESB is used in a typical enterprise application.
The picture shows how ESB is used in a typical enterprise application.
Comments