Enterprise Service Bus Q&A (Part I of II)


IT Integration for Customer Experience

In our first two reports on IT integration for customer experience,*1 we covered a lot of ground, discussing the business and technology drivers for enterprise integration, the overall integration solution landscape, an eleven-point best practice integra-tion strategy for customer experience, and the pillars of that strategy: scenario-based integration and a networked integration environment.

Now, we are ready to discuss transitioning the networked integration environment (NIE) from an architectural view to a realized infrastructure, starting with the NIE backbone. As we mentioned in our last report, there are pertinent solutions from the service-oriented architecture (SOA) space that can provide NIE functions. One of particular note is the enterprise service bus (ESB), which is a viable candidate for the NIE backbone.

Unfortunately, the ESB is awash in confusion, propelled by the industry’s need to associate products with service-oriented architecture. So, before we dive into a series of deep technical and product analysis reports on leading ESB solutions, we thought it was important to answer the major questions surrounding ESB.

Those questions are:

  1. What is an enterprise service bus?
  2. Is an enterprise service bus an architecture or a product?
  3. What are the enterprise service bus features and functions?
  4. What does the enterprise service bus look like?
  5. Is the enterprise service bus here to stay?

Before addressing the ESB questions, we provide a recap of the key concepts from our earlier integration reports: scenarios, shifts in application development and information delivery, and the networked integration environment.

Scenarios and Integration

There are three critical, interrelated views of integration—customer, business, and IT—each taking the form of a scenario. The customer’s scenario (her ideal experience) drives the business and IT scenarios.

From the customer’s point of view, integra-tion refers to her total experience. A customer views integration as consistency, accuracy, unified information access, seamless interactions, and relevant, tailored-for-me company outreach.

To fulfill the customer’s view of integration, business personnel think about the processes, infor-mation, systems, and hand-offs that need to be in place to support the customer’s scenario. In addition, the business thinks about how to fund and measure the execution of the scenario. From the business point of view, integration is process and information, supported by systems.

IT personnel take in both the customer and business views of the scenario and identify the resources (applications, services, information, and in-frastructure) that are required to fulfill the scenario and how those resources should be composed into IT business solutions, via integration scenarios. In addition, IT considers implementation details such as physical resource connections, performance, timing, security, service levels, and investments.

Shifts in Application Development and Information Delivery

To meet customer expectations while remaining profitable and competitive, IT is starting to shift away from the delivery of traditional applications and information bases toward the fulfillment of scenarios. IT is combining services, events, and business processes to deliver crosscutting business scenarios and right-time information. The techniques employed include service orientation,*2 composition and choreography,*3 event processing, find, federation, transformation, and filtering. Implied within these techniques is integration. In other words, application development and information delivery now have “integration inside.”

The Networked Integration Environment

The networked integration environment is based on the premise that application infrastructure solutions should employ these same powerful tech-niques, particularly service orientation and composition and choreography.

The networked integration environment hosts integration services*4 whose purpose is to perform integration tasks. These integration tasks may be simple (data translation), medium (information publication/subscription), or complex (choreographing a multiparty, multi-resource business process). By offering integration as scenarios and services, IT business solutions then become agile compositions of services (business, systems, integration), events (business, systems), and process (business scenario, integration sce-nario).

Since providing discrete integration services alone is not enough, the networked integration environment must also provide an integration backbone with services such as discovery, routing, security, and connection binding. In addition, there must be functionality to monitor and manage the networked integration environment along with the execution of integration scenario instances.

Illustration 1 is a logical depiction of the networked integration environment, shown in relationship to key elements of IT business solution and infrastructure operations. For the purpose of this report, we focus on the backbone integration services.

BACKBONE INTEGRATION SERVICES. The backbone integration services provide the core integration functionality: integration service and integrated resource discovery, message routing, integration service and integrated resource policy enforcement (authentication, authorization), connection binding, transaction control, and audit. With only backbone services in place, you could do sim-ple integrations such as service orchestration, request/reply, request/forward, file drop, and message delivery. The connection protocols of the integrated resources could vary, but there would have to be agreement on the message data. Data translation and transformation are add-on services, residing in the system-oriented integration services category.

As we’ll discuss below in Question 3, enterprise service buses typically provide the functionality of the backbone integration services, plus the services for data translation and transformation. For a detailed description of the networked integration environment, including the functions present in each layer, please refer to our report, “Integration Scenar-ios and the Networked Integration Environ-ment.”*5


With that quick review complete, it is time to ask and answer the hot enterprise service bus questions. These questions have been the subject of great industry discussion in the press, in blogs, and during webinars. Here are our views.

Question 1: What Is an ESB?

ESB DEFINITION. An ESB is an open standards, message-based, distributed, integration solution that provides routing, invocation, and mediation services to facilitate the interactions of disparate distributed information technology resources (applications, services, information, plat-forms) in a reliable manner. That’s a lot to take in, so let’s break down the key terms in our ESB definition, as follows:

  • Open Standards. Open stan-dards refers to both the ESB solution compo-nents (runtime container, messaging infrastructure, integration services, design-time notations) and the mechanisms for inte-grated resources to participate (attach, request, respond) on the bus.
  • Message-Based. The communication mechanism of an ESB is messaging, using standard message notation, protocols, and transports.
  • Distributed. The ESB runtime environment can be distributed across a networked envi-ronment for the purposes of quality of service, quality of protection, and economics.
  • Routing, Invocation, and Mediation. Routing, invocation, and mediation are the ba-sic functions of the ESB. Routing includes address-ability and content-based routing. Invocation refers to the ability to make requests and receive responses from integration services and integrated resources. Mediation refers to all translations and transforma-tions between disparate resources including security, protocol, message notation/format and message payload (data/semantics).
  • Facilitate. The ESB must coordinate the interactions of the various resources and provide transactional support.
  • Reliable. The ESB must guarantee message delivery.

ESB USAGE. There are two major uses of the ESB. The first is for enterprise integration, the connection of disparate resources to fulfill customer and business scenarios. The ESB is a standards-based integration alternative to traditional proprietary enterprise application integration (EAI). The ESB has gained popularity in IT shops that have adopted a service orientation, since the integrated resources in an ESB and the integration functions act as services. The role of an integrated resource as a service is critical, because now the integrated resource can easily participate in a service-oriented architecture, as described next.

The second use of the ESB is as an infrastructure backbone for service-oriented architecture (SOA). The ESB serves the two primary styles of SOA: composite application development and event-driven/process-driven SOA. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. In composite application development, the ESB provides service request routing, invocation, mediation, and inter-service orchestration.

In event-driven SOA, an event (a meaningful business or system thing) happens, which causes a series of (seemingly unrelated) actions to initiate. Those actions can include the invocation of services and business processes. In event-driven SOA, in addition to the functions mentioned above, the ESB serves as the event processor, interpreting and han-dling events based upon content, rules, and subscriptions, to initiate the appropriate downstream actions.

In process-driven SOA, a business process can be implemented as a service (a long-running transaction), and/or a business process step (activity) can invoke one or more services. Similar to event-driven SOA, an automated action triggers the invocation of services. In process-driven SOA, the ESB performs the functions mentioned above, and it can also host a business process execution engine to control the long-running process. As we described in our report, “The Evolution of Service-Oriented Architecture,”*6 we believe the true power of SOA is combining business process, events, and services in the same interaction.

The ESB’s ability to perform integration tasks and service-oriented architecture tasks makes it a great candidate for the networked integration environment backbone.

*1 See “Integration and Customer Experience,” Brenda M. Michelson, March 31, 2005, http://dx.doi.org/ 10.1571/BDA3-31-05CC, and “Integration Scenar-ios and the Networked Integration Environment,” Brenda M. Michelson, April 14, 2005, http://dx.doi.org/ 10.1571/BDA4-14-05CC.

*2 Service orientation is an architectural concept that refers to the loose coupling of a service (an abstract resource with a defined job) from its provider (the physical asset or assets that perform the job tasks). A requester only knows what the service’s job is and how to request it. The service is the only thing that knows its implementation.

Service-oriented architecture (SOA) is an IT ar-chitecture strategy for business solution (and infrastructure solution) delivery based on the concept of service orientation.

*3 Composition refers to combining multiple resources (of any type—application, information, or human) to complete a task or serve a larger purpose. Choreography refers to the sequencing and coordination required in composition.

*4 A service is a thing that fulfills a purpose. A service is an abstract resource that has a name, a job, job tasks, contact information, and policies regarding security and service levels. To use (request) a service, you send a message in accordance with the contact information and policies and then (if appropriate) you receive a reply message.

*5 See “Integration Scenarios and the Networked Integration Environment,” Brenda M. Michelson, April 14, 2005, http://dx.doi.org/10.1571/BDA4-14-05CC.

*6 January 6, 2005, http://dx.doi.org/10.1571/SOA1-6-05CC.

For the second part of this article, please click here: http://www.ebizq.net/topics/esb/features/6132.html

About the Author

Brenda Michelson is an IT strategist, hands-on practitioner, and the voice of business-driven architecture. Brenda’s day job is principal consultant for Elemental Links. Brenda also contributes architecturally to the Patricia Seybold Group. Brenda spent 19 years in corporate IT, most recently as Chief Enterprise Architect for L.L. Bean. At L.L. Bean, Brenda was responsible for the articulation and execution of the enterprise architecture strategy (J2EE transformation, enterprise integration, SOA and EDA), strategic planning, portfolio management and talent development. Previous to L.L. Bean, over the span of 10 years, Brenda provided development services for Insurance, Banking, a Chip Manufacturer and a world leader in Aircraft Engine Design & Manufacturing. Email Brenda.

More by Brenda M. Michelson

About Elemental Links

Elemental Links is an IT consulting and advisory practice specializing in strategy, architecture, and portfolio planning for business-driven IT.