As with any other concept or acronym in IT, ESB has had its fair share of deviation of definitions across vendors and corporate project teams. So I figure I’d survey some definitions from the top players in the space…
The term Enterprise Service Bus (ESB) is widely used in the context of implementing an infrastructure for enabling a service-oriented architecture (SOA). However, real-world experience with the deployment of SOAs has shown that an ESB is only one of many building blocks that make up a comprehensive Service-Oriented Infrastructure (SOI). The term ESB has morphed in a number of different directions, and its definition depends on the interpretation of individual ESB and integration platform vendors and on the requirements of particular SOA initiatives.
Based on the experience Microsoft has gathered from many successful real-world SOI implementations, you can think of an Enterprise Service Bus as a collection of architectural patterns based on traditional enterprise application integration (EAI), message-oriented middleware, Web services, .NET and Java interoperability, host system integration, and interoperability with service registries and asset repositories.
Mule ESB is based on the concept of a service-oriented architecture (SOA). The SOA approach to development allows IT organizations to compose applications by building service interfaces around components of applications and exposing those to service consumers. Services are discrete sets of functionality that are completely separate from each other but can work together on a canonical set of objects. For example, if you need to process customer invoices, you might have one service that merges customer data from a database into the invoice and another service that checks the inventory database to see if the items on the invoice are in stock and a third service that fulfills the order.
Because each service stands alone, services can be used as building blocks for multiple processes and do not have to be recreated for each type of process or message. For example, the service that merges customer data onto the invoice could also be used to merge customer data onto statements, letters, or other documents. The logic that determines how the invoice data and customer data are merged is decoupled from the logic that looks up and retrieves the necessary customer data. This modular approach allows you to create functionality once and re-use it as many times as needed, streamlining development.
This decoupling is a key element of service mediation. Mediation is a well-known pattern for promoting loose coupling. In SOA, service mediation also describes the capabilities of the ESB to convert between transport protocols (including the ability to bridge between synchronous and asynchronous protocols), changing the representation of messages by transforming data, and enforcing compliance with policies by taking the necessary steps such as auditing, logging, security monitoring, etc.
Constructing the building blocks into a logical process is called orchestration. Service orchestration using an ESB allows for automation of common backend processes at the application service layer. These processes can be scheduled or exposed as services that are triggered by external events. Service orchestration differs from business process orchestration which may include longer running stateful business processes, complex human interactions and approvals, or parallel execution of those types of processes at the business service layer.
Using SOA, businesses can realize dramatic savings on development costs and can rapidly adapt to changing business conditions by reusing and reconfiguring existing services in developing new applications. SOA also enables better integration of enterprise IT resources, including previously isolated application silos and legacy systems. Mule fully supports the SOA approach and orchestrates communication among the services, allowing you to easily tie all these applications together.
An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in service-oriented architecture (SOA). As a software architecture model for distributed computing it is a specialty variant of the more general client server software architecture model and promotes agility and flexibility with regards to communication and interaction between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex landscapes.
The concept has been developed in analogy to the Bus concept found in computer hardware architecture combined with the modular and concurrent design of high-performance computer operating systems. Motivation was to find a standard, structured and general purpose concept for describing implementation of loosely-coupled software components (called: services) that are expected to be independently deployed, running, heterogeneous and disparate within a network. ESB is also the intrinsically adopted network design of the World Wide Web and the common implementation pattern for Service Oriented Architecture.
An ESB transports the design concept of modern operating systems to networks of disparate and independent computers. Like concurrent operating systems an ESB caters for commodity services in addition to adoption, translation and routing of a client request to the appropriate answering service.
The prime duties of an ESB are:
- Monitor and control routing of message exchange between services
- Resolve contention between communicating service components
- Control deployment and versioning of services
- Marshal use of redundant services
- Cater for commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service
IBM (From a WebSphere ESB perspective)
WebSphere® ESB provides the capabilities of a standards-based enterprise service bus.
WebSphere ESB manages the flow of messages between service requesters and service providers. Mediation modules within the ESB handle mismatches between requesters and providers, including protocol or interaction-style, interface and quality of service mismatches. In an SCA-based solution mediation modules are a type of SCA module. The mediation modules perform a special role, and therefore have slightly different characteristics from other components that operate at the business level.
Mediation components operate on messages exchanged between service endpoints. In contrast with regular business application components, they are concerned with the flow of the messages through the infrastructure and not just with the business content of the messages. Rather than performing business functions, they perform routing, transformation, and logging operations on the messages. The information that governs their behavior is often held in headers flowing with the business messages. The IBM® SOA programming model introduces the service message object (SMO) data structure to support this pattern.
WebSphere ESB supports advanced interactions between service endpoints on three levels: broad connectivity, a spectrum of interaction models and qualities of interaction, and mediation capabilities. The product supports connectivity between endpoints through a variety of protocols and application programming interfaces (APIs):
- Java™ Message Service (JMS) 1.1. Applications can exploit a variety of transports, including TCP/IP, SSL, HTTP, and HTTPS.
- WebSphere ESB supports Web services standards that enable applications to make use of Web service capabilities.
- SOAP/HTTP, SOAP/JMS, WSDL 1.1
- UDDI 3.0 Service Registry, through the WebSphere Integration Developer
- WS-* Standards including WS-Security, WS-Atomic Transactions
Because it is built on WebSphere Application Server, WebSphere ESB can provide smooth interoperability with other products in the WebSphere portfolio, including IBM WebSphere MQ and IBM WebSphere Message Broker. It can also, with IBM WebSphere Adapters solutions, use existing application assets, as well as capture and disseminate business events.
The message clients for C/C++ and Microsoft .NET enable non-Java applications to connect to WebSphere ESB using an API similar to the JMS API.
Other features at the connectivity level perform basic protocol conversion between endpoints where the protocol used by the requester to dispatch requests (such as SOAP over HTTP) is different from that of the service provider that is to handle those requests (such as SOAP over JMS).
An enterprise service bus (ESB) is the key to unlocking value from active business data. Essentially a shared superhighway for data, messages, and events to travel on, it enables systems and applications to communicate and work together.
Connecting systems and applications to a common, bus-based backbone, real-time information can circulate across the environment. Data is instantly available and can be accessed, consumed, and acted on by any system, application, or business processes on the network.
Events happening across the environment can also be made available – providing the visibility and awareness critical to engaging with activity in real time. By including traffic enterprise-wide, you can be more aware of when opportunities and threats emerge and respond with greater precision and control.
Any component can be connected, ejected, or modified without impacting the performance of others. Automatic routing and transforming messages between components ensures data arrives in the proper usable format.
Used as a foundation for a service-oriented architecture (SOA), [TIBCO ESB solution, currently ActiveMatrix] can also help expose valuable data and functionality trapped in application siloes and enable them for reuse. Grid-based architecture provides the capacity to quickly configure load balancing and fault tolerance for high availability and uniform lifecycle management of all services independent of technology.
TIBCO ActiveMatrix® Service Bus is a lightweight enterprise service bus (ESB) that mediates the communication between applications and services by routing and transforming disparate data formats and transport protocols.
It supports rapid development, near-zero coding, and low maintenance. Its standards-based platform reduces complexity and increases flexibility and reuse by replacing hard-coded service dependencies with configuration.
Highly scalable, its elastic backbone can also reliably support high availability requirements, enabling you to quickly onboard services from third-party environments or a TIBCO-based infrastructure.
Progress Software (formerly Sonic Solutions)
A service oriented architecture (SOA) will change the way you integrate and manage information assets. With a SOA infrastructure, old systems and applications are no longer lost investments – they can be reconfigured as modular services and made available throughout your enterprise.
Having an enterprise service bus (ESB) makes it easy to enjoy the key benefits of a SOA infrastructure, which are maximum flexibility and simplified management. As an added bonus, the enterprise service bus also also makes it easier to reduce the cost of IT investments by better enabling older or legacy systems to be reused.
Moreover, because the ESB primary function is to connect people, processes, and systems with the right information at the right time with greater performance and high availability, the ESB is therefore a fundamental building block for advanced Responsive Business Integration (RBI) architectures.
RBI enhances and complements application development with modular components that enable design for continuous change. And with an intelligent, policy-driven ESB infrastructure to underpin RBI agility, enterprise organizations stand a far better chance of realizing the many benefits of a successful SOA.
Providing flexible integration of distributed services and applications within an SOA, the Sonic ESB distributed architecture combines independently scalable integration services, intelligent routing, and an enterprise messaging backbone. Customers use Sonic ESB to reduce process cycle time, gather and disseminate information, and reliably respond to business conditions as they occur.
Sonic ESB enables the creation of federated services by allowing architects to more easily manage the SOA from any point. Hard-wired dependencies are eliminated through configurable service interaction, so it’s easier to deploy projects initially and – without need for disruptive re-programming – allow them to scale and evolve, extending their value throughout the organization.
Sonic ESB allows all resources to be readily connected and made broadly available across the enterprise – Web services, J2EE applications, legacy message brokers, and more. By making these federated services available for dynamically-configured interaction with other services, Sonic ESB allows the organization to bring IT resources into better alignment with organizational requirements.
An ESB is an infrastructure platform that fills critical interoperability gaps left open in state-of-the-art standards. More importantly, it enables interoperability across dissimilar standards which often exist in modern computing environments. Along the way, it brings a higher level of robustness to the infrastructure necessary to meet the mission-critical performance, reliability and scalability needed by contemporary enterprises.
In the SOA logic chain, interoperability is the predicate to agility and reuse. However, ‘true’ interoperability must be assessed on multiple dimensions, all of which must be in alignment between services if genuine interoperability is to occur. These dimensions of alignment fall into four broad categories: Functional, Structural, Behavioral and Performance.
For a consumer service to use a particular provider service, it must be aligned on the functional requirements. The provider must do what the consumer wants, whether it’s computing a price, looking up a customer, updating and order or responding to an event of interest. While the functionality is up to the service, there are other considerations which may or may not be handled by the service itself.
• . Structural or systemic, alignment might be thought of as aligning the ‘pin-outs’ of an interface. If the pins between a printer and the PC don’t match, the printer won’t print, even if your PC is perfectly capable of driving a serial printer. In SOA, this type of alignment is manifest in the protocols and formats employed by the consumer and provider services. They must align precisely or interoperability will not occur, even if the provider delivers the correct function.
• Behavorial alignment extends to more intangible notions such as semantics and interaction. With respect to semantics, a consumer service may request a ‘customer’ business object, but the provider service produces business objects called ‘party’ and types the object with an attribute enumerated as customer, vendor, partner, supplier, etc. While the provider is capable of producing the desired information, and the ‘pins are in alignment’, the interpretation of the produced result may or may not be natively intelligible by the consumer because the semantics are different. Similarly, with respect to interaction, there may be a consumer that wants to ‘inquire’ for customers when needed, while there may be a provider service that wants to ‘publish’ customer business objects each time one is created or updated. Although all other aspects of interoperability may be in alignment, if one wants to ask for customers and another wants to broadcast them on particular events, there still won’t be interoperability because the behavior of dialog is out of alignment.
Performance encompasses issues beyond direct interoperability; these are considerations having to do with Quality-of-Service (QoS) and Quality-of-Protection (QoP), or simply the entire realm of service-level and security-policy. Alignment here is equally critical. If a provider service was built to handle 2 requests per second with 1 second response time, consumers must be aligned with that service-level expectation or realistic production interoperability cannot be achieved. Likewise, if a provider service was deployed with the expectation that it would only be consumed by internal services, and was then inadvertently exposed for consumption by a public audience, it would be out of alignment with expected security policy.
The point to all of this is that real-world interoperability is only possible when all aspects of alignment are achieved. However, the choice of where to implement the last three of these categorical considerations is critical to the question of reuse. While the functional aspects of interoperability indeed rest entirely with the services themselves, if the services also take on the responsibility for structural, behavioral and performance related concerns, reuse erodes rapidly and the chain of logic supporting SOA unravels.
If services were left to ‘fend for themselves’ on all these points they would either come up short on support for requirements essential to certain contexts or they would become increasingly bulky . Moreover, the services would be more costly to develop, operate and maintain and would lead to duplication of those capabilities across multiple services with inconsistencies between them.
On the other hand, services that indeed delegate all these considerations entirely to common infrastructure, become inherently more reusable across more contexts and thus become more agile and manageable at scale—preserving the SOA chain of logic. ESB is this common infrastructure onto which a service can delegate mediation of these concerns. Simply put, ESB is a mediation layer for enterprise SOA whose express purpose is to mediate differences in structural, behavioral and performance characteristics between services.
ESB extends the basic idea of abstraction between participants (providers and consumers) to enterprise scale. ESB permits services (consumers and providers) to interact in a loosely-coupled manner; more so than if they were simply connected point-to-point using the most contemporary loose-coupled standard protocols, like WebServices or Java Message Service, alone. This enables services, and the processes that use them, to change over time, at a faster rate and to a much greater degree, without affecting other services or processes around them.
This is the foundation for agility.
Oracle (from an Oracle Service Bus stand point)
Oracle Service Bus transforms complex and brittle architectures into agile integration networks by connecting, mediating, and managing interactions between services and applications. Oracle Service Bus delivers low-cost, standards-based integration for mission critical SOA environments where extreme performance and scalability are requirements.
Oracle Service Bus 11g introduces new capabilities such as Service Result Cache, RESTful API, and improved performance and availability for organizations using enterprise datacenters, as well as mobile and cloud environments.
- Oracle: Enterprise Service Bus (soadevelopers.wordpress.com)
- ESB Does Not Equal SOA; Learn the Real Equation (thetibcoblog.com)
- Giovani Salvador: Java, SOA and XML (soadevelopers.wordpress.com)
- SOA and REST with Grails (architects.dzone.com)
- SOA World Magazein: ESB Integration Patterns (soadevelopers.wordpress.com)
- Working With Open Source Enterprise Service Bus in Java (soadevelopers.wordpress.com)
- ESB Built for IoT (mholdmann.wordpress.com)