Enterprise Service Bus (ESB)

To integrate old and new, service-oriented architecture (SOA) needs an infrastructure that can connect any IT resource, whatever its technology or wherever it is deployed. To be flexible, it needs an infrastructure that can easily combine and re-assemble services to meet changing requirements without disruption. And to be dependable, it needs an infrastructure that is robust and secure.

This infrastructure is the enterprise service bus (ESB).

An ESB is software infrastructure that simplifies the integration and flexible reuse of business components within a service-oriented architecture. An ESB provides a dependable and scalable infrastructure that connects disparate applications and IT resources, mediates their incompatibilities, orchestrates their interactions, and makes them broadly available as services for additional uses.

In most organizations, technological heterogeneity is more the rule than the exception. To integrate applications within an SOA, it is necessary to both span new service-enabled applications as well as existing applications. An enterprise service bus simplifies connection of new applications, web services, and hundreds of other technologies, including batch files, application servers, legacy middleware products and packaged applications.

Built-in mediation capabilities make it straightforward for the ESB to reconcile the incompatible protocols, data formats and interaction patterns of disparate connected resources. Data represented in XML is readily transformed using XSLT or XQuery services and routed to particular downstream systems based on their content or other attributes. Data may be split, aggregated, and enriched en-route to a consuming service. For example, a batch file containing customer orders can be broken down into individual transactions, with each transaction enriched with customer and product information before subsequent routing and delivery to specialized order fulfillment systems. Order fulfillment systems best served by batch files can be incorporated by aggregation of the transaction flow back into batch form. Intermediary services such as these allow integration architecture to eliminate dependencies between service consumers and service producers, making it easier to create a loosely-coupled system that can be changed without disruption.

Service orchestration provides a means to automate the invocation of multiple services, managing complex flow logic and process state, and correlating responses from downstream systems to a given orchestration instance. Orchestration supports process automation by invoking services in a particular order and by following a set of rules. Orchestration offers a top-down, process-oriented approach to SOA, allowing the modeling of a process in the abstract, followed by subsequent specification of technical details for the implementation of individual process steps. Service orchestration also makes it easier to monitor and manage the execution of these processes as they run, and also makes it easier to change process definitions to adapt to new business requirements.

Finally, an enterprise service bus makes services available for broad access and re-use. Here, communications capabilities of the underlying enterprise messaging backbone come to the fore. Properly engineered, they provide not just the dependable, robust and secure communication for service access, but also support communication across firewall's and LAN boundaries in a seamless manner. The enterprise messaging backbone also provides the publish-and-subscribe semantics that support an event-driven model in which any number of service consumers can respond to a business event. These rich messaging semantics enhance service re-use by make it easy to dynamically add new service producers and consumers to the scenario at runtime, without requiring a recoding of a process or service.

Users of an enterprise service bus typically follow an incremental, leave-and-layer approach to project implementation. Existing applications and SOA infrastructure are left in-place. Whether automating or streamlining a process, gathering and disseminating information, or responding to business events, the ESB is deployed and configured to accomplish a particular business change objective. At the same time, the ESB lays a highly flexible and scalable architectural foundation for additional projects, providing the basis for extension and re-use of these projects to meet additional user requirements. The incremental approach allows the rapid delivery of value to users, thereby reducing the risk that requirements change before the project is complete, and at the same time executing on the vision of an SOA for long-term business agility and broad-scale interoperability.

Because ESB architecture and function varies from vendor to vendor, when selecting ESB technology for integration within an SOA, it is necessary to inspect a given implementation closely. There are five principal aspects that need to be considered when selecting an ESB:

1. Performance and scalability - It is essential that the infrastructure used to integrate within an SOA provide the performance expected of enterprise systems while easily accommodating changes in demand. It is critical that an ESB not create bottlenecks or chokepoints in the infrastructure that would restrict the breadth of its deployment or limit the throughput of data it can carry to and from connected resources. Unlike traditional hub-and-spoke integration broker technologies, an enterprise service bus with a distributed architecture will facilitate the distributed processing of services, service orchestration and the underlying communication infrastructure. While distribution is an effective means to ensure high throughput and scalability, it is important that physical deployment not impact the logical or semantic behavior of the infrastructure, and that a highly distributed infrastructure be straightforward to manage, monitor and control.
   
   
2. Security, reliability and availability - An ESB should provide configurable enterprise-level quality of service to ensure that service communication is as secure and reliable as needed to meet a particular business requirement. By providing these guarantees, service developers can depend on these features, dramatically simplifying the job of service development and focusing activity on development of business logic, not integration logic. For example, producer services themselves need not manage data re-transmission if consumer services are temporarily unavailable; infrastructure which guarantees delivery will store the data and forward it when the consuming service is available. Highly available SOA integration infrastructure isolates applications from faults resulting from server and communication failures. A true highly available ESB will present itself to services as not only a reliable infrastructure, but one whose integration services are continuously available, even if a component in its distributed infrastructure should fail.
   
   
3. Distribution - In an SOA, services and service orchestrations will interact with services spread across an organization, and between organizations. An ESB provides the communications facilities which link them together with configurable qualities of service and messaging semantics, with both queuing and publish-and-subscribe behavior. This allows the gathering and distribution of data, as well as the notification of business events and correlation of replies of subscribing services. In a federated SOA environment—one in which services cross organizational boundaries—or in a distributed environment—one in which service communications bridge geographic boundaries—it is critical that data, events, and replies are directed to the right place at the right time, without management overhead. Advanced distribution capabilities allow flexible extension of the ESB to incorporate and connect resources in additional security domains without any reconfiguration or disruption of running systems.
   
   
4. Flexibility - The flexibility of a properly architected enterprise service bus allows an organization to change orchestration, rules, data mapping and relationships between applications with minimal effort and disruption. Here, the core requirement is that it be possible to dynamically change services, process and schema without disruption of running systems. At the same time, the architecture must afford complete freedom to define and change physical deployment for efficient, scalable processing without any impact to the semantics or behavior of integrations. Sophisticated publish-and-subscribe semantics allow the simultaneous broadcast of information or notifications of business events to a potentially large number of interested parties, and also make it easy to expand the system without making changes to the service provider. Service mediation eliminates inflexible, hard-coded service interdependencies, which are the enemy of SOA flexibility because they make it difficult to understand the impact of a change in a service. By isolating services from one another, the ESB creates a framework for loosely-coupled integration, thereby enabling much easier management of change in a complex environment. Finally, service orchestration provides a flexible way to model, define, and manage processes that direct the sequenced interaction of services. Advanced service orchestration facilities will provide the capability to manage both high-throughput and long-running process scenarios in the ESB.
   
   
5. Visibility and control - An ESB should manage and monitor the infrastructure as well as the processes and services deployed within it. The first task of management is the deployment of services, which may be hosted anywhere the ESB runs. Since a deployment may be highly distributed, such as a retail deployment comprising hundreds or thousands of stores, the ESB should make it easy to deploy and upgrade services remotely from a central location. To provide dynamic, run-time control, an enterprise service bus is configuration-driven: services are parameterized and their mediated relationships are declared, so they may be changed without re-compilation and re-deployment. This allows the modification of data and process flow without shutting down running services. For federated environments, it is critical that the ESB management domain seamlessly bridge LAN boundaries and security domains; the ESB should allow visibility and control across the entire federated environment. To facilitate development in a real-world, distributed environment, the ESB needs real-time message tracking and distributed flow control debugging. Finally, in order allow the diagnosis and management of problems in complex distributed systems, administrative features should provide logging and auditing of services, as well as the monitoring of faults, service and process status, and detailed performance statistics of the ESB communication infrastructure.

Benefits of an Enterprise Service Bus

IT Benefits:

• Reduces time and effort to integrate new and existing applications.
• Creates new processes through the reuse of existing applications and data.
• Increases flexibility to change complex system behavior by minimizing the hidden dependencies among applications, services and middleware in a distributed environment.
• Reduced TCO and greater flexibility to accommodate future needs through use of industry-standard interfaces and protocols.
• Reliably delivers messages across services, even after software, network or hardware failure.
• Provides a service hosting and management infrastructure that is highly distributed, yet centrally managed.
• Disseminates information throughout the enterprise, as well as to customers and trading partners.
• Can be deployed incrementally, speeding delivery of service to customers and reducing risk for large, complex projects.

Business Benefits:

• Integrated business systems: reduced cycle times, reduced operating expenses, improved customer service, facilitated mergers and acquisitions, easier and more accurate decision-making based on up-to-date business information for "single version of the truth."
• IT cost reduction and control through standardization of reusable business components.
• Improved responsiveness to change business processes quickly and effectively.
• The ability to respond to special business conditions as they occur.

Contact us to gain more insight and to learn more about partner programs from Progress Software.

Related Topics

• SOA Maturity Model
• Service Oriented Architecture
• Messaging Software
• SOA Management
• Semantic Integration

You may also be interested in:

• Evaluate Sonic ESB
• ESB Resource Center
• Sonic Customers
• Partner Programs
• Press Releases