Part 2: Wiring Through an Enterprise Service Bus

An Enterprise Service Bus (ESB) is an integral part of any enterprise-scale SOA, for a host of reasons.

Downloads for this article: Oracle SOA Suite and Services Registry

Published October 2006

As the idea of implementing Service Oriented Architecture (SOA) gains traction, enterprises are finding themselves with an increasingly large portfolio of services. Effectively leveraging and reusing these services can prove challenging unless you follow the correct architectural patterns.

The use of an Enterprise Service Bus (ESB), a relatively new software category, is one such pattern. It provides a much-needed intermediary layer that facilitates data delivery, service access, service reuse, and service management of an enterprise SOA implementation. ESB also supports intelligently-directed communication and mediates relationships among loosely coupled and decoupled business components.

In this installment of "Mastering SOA," you will learn why an ESB is an integral part of enterprise-scale SOA and get an introduction to implementing an ESB, including common pitfalls.

Do You Need an ESB?

As explained in Part 1 of this series, SOA is a fundamental shift in the way applications are designed, developed, and integrated. It also facilitates the development of enterprise applications as modular business services that can be easily integrated and reused. However, SOA also implies a variety of challenges, many of which can be directly addressed with an ESB:

• Reliable Messaging: Reliable transport of data continues to be a basic need for any integration solution. While the principle of SOA calls for standards-based, platform-independent messaging protocols, this principle does not inherently allow for reliable delivery of data. Standards (such as WS-RM) are emerging to support this capability, but they are not yet mature or widely adopted.
• Service Virtualization: SOA implies a basic architectural paradigm in which any service consumer can access a service provider from any platform. This, in turn, implies that the appropriate protocol and syntactic mediation is in place to insulate consumers and providers.
• Dynamic Discovery and Invocation of Services: In order to optimize reuse of services, service consumers require an intermediary function to understand the characteristics of the service request, and facilitate the connection with the provider. In an ideal SOA, this relationship would be brokered at run-time.
• Policy Management: Access by known and unknown service consumers results in the need for an abstracted policy management model that is capable of enforcing authentication, authorization, and encryption in addition to more complex business-level policies independent of the service provider implementation.
• Management and Monitoring of Services: An increasing number of services results in an increasingly complex environment. This environment must be monitored for availability, performance, and any technical or business-level errors.
• System Heterogeneity: Today's new applications are tomorrow's legacy, as one can observe in common applications as well as the software used to connect them. This proliferation of new technology is inevitable, and system landscapes must be architected to support such change.
• Abstraction of Business Logic from Technical Implementation Details: One goal of SOA is to provide a layered approach to developing systems that insulates changes in technology from changes in business process, and vice versa. In effect, this "separation of concerns" must be designed into the architecture from the start.

Prerequisites for ESB Deployments

Before going into further details, let's step back and recognize that not all SOA implementations will require significant reuse and loose coupling. Smaller implementations, for example, may draw only marginal benefits from the addition of an ESB.

You will need to meet several tactical conditions to establish the need for an ESB. In order of importance, these conditions are:

1. Service consumers and providers may be loosely coupled or there is a need for synchronous, non-deterministic routing (where consumer requires a response but does not explicitly know the service provider).
2. There is a need to execute specialized functions based on the data, consumer, or provider before executing the business transaction (may include policy validation, transformation, and so on).
3. There must be a way to connect end-point applications to the bus (either through re-architecting or via adapters), and it must be possible to operate them in a service-oriented model (Not all applications can be easily service enabled. For example, traditional legacy programs, such as customer data applications, operate using a batch-based programming model connected to legacy screens. These may not be easily adapted to the more transaction-based SOA paradigm.)

As with all complex computing architectures, these three conditions are merely guidelines. There are certainly situations where it is easy to justify an ESB without meeting all three of them. When embarking on an SOA roadmap, be sure to include not only the tactical concerns, but also consider long-term strategic objectives.

Top-Down vs Bottom-Up

The two main methodologies for SOA are often referred to as "top-down" and "bottom-up". In a top-down approach, SOA adoption is driven by the business side and the result is an architecture specifically tailored to meet the business needs, with a focus on efficiency. The more pragmatic bottom-up approach is often sponsored by the IT branch of the organization and is more concerned about service virtualization, with the primary goal of minimizing costs and weaving more flexibility into core IT assets.

As you can imagine, there is a healthy debate around which path is the most appropriate or efficient. We will not take side here and instead ask ourselves whether an ESB is relevant to both approaches.

The answer is "yes"—an ESB is usually required in top-down as well as bottom-up SOA roadmaps. The tools involved do not vary much from one approach to another; it is the timing of their introduction that does. In a bottom-up approach, ESB is likely to be used right from the very early stages, to perform low-level data and system integration. In a top-down approach, the initial focus might be on building services, but ESB will enter the picture later, when it is time to interconnect those services.

Common Use Cases

An exhaustive list of all possible use cases would require a much longer article. However, it is worth highlighting some of the more common ones:

Service Virtualization. Service virtualization is the primary driver for implementing an ESB, and most other use cases are variations of it.

Lack of clean layering—or "separation of concerns"—at design time introduces unnecessary coupling between business logic and IT details. The impact of these cross-dependencies might not be noticeable at first, but as the integration scope grows, they start to erode the initial benefits of a SOA implementation at an exponential pace. Each addition of a direct link to an endpoint adds inertia to petrifying what was initially started as a flexible, loosely coupled architecture.

For instance, relocating a database from one network to another will require a new version of the loan approval process when endpoint details are embedded within it. Addressing a couple of these links might be manageable, but if you extrapolate this picture to 50 services and dozens of endpoints, you can see that the architecture will soon turn into an inextricable Web of dependencies.

This example also exposes the unnatural relationships that such design introduces between IT events (a database move) and business logic (the loan approval process). It is unacceptable for routine IT events to trigger complete versioning of complex and core business assets, such as the loan approval process, when these assets have not changed at all.

Of course, this trivial example could have been minimized with careful configuration and use of such techniques as JNDI or DNS, but it is a convenient illustration of the problems that service virtualization can solve. More realistic use cases involve adding or removing databases, changing CRM vendors, or even absorbing the new systems that came as a result of a merger or an acquisition.

Service virtualization, as illustrated in Figure 1, is key to preserving the growth-capabilities of a service-oriented architecture. By using an ESB, one can extirpate all the endpoint details such as IP addresses, ports and other low-level, machine-specific details from the business logic and instead expose a single, stable interface. The net result is a clean separation of business concerns from IT concerns, allowing both IT and business to independently revision their respective assets.

Figure 1 Service virtualization

Centralized control over policies. Gone are the days when all you had to monitor was a couple of application server log and config files. Fortunately, an ESB can help you address the management and monitoring of problems inherent in today's distributed systems--offering an end-to-end view over multiple applications and protocols, and configuring and enforcing global policies across the enterprise.

Because an ESB logically brokers all your integration communications, the monitoring of your SOA infrastructure becomes simplified. The ESB management console provides a consolidated view of all exchanges and messages flowing across services. (See Figure 2.) These new monitoring capabilities can be used for passive as well as active monitoring. For instance, building and enforcing end-to-end service level agreements (SLAs) become possible. The actual monitoring platform might be an external application—such as OpenView or Tivoli or perhaps newer business activity monitoring (BAM) tools, now increasingly used for real-time infrastructure monitoring—but the ESB provides the required consolidated, standards-based (SNMP, JMX, SQL) view into the infrastructure.

Figure 2 Centralized control over policies

Global rollout of policies such as security or reliability is easier with an ESB. By exposing standardized hooks (WSDL interfaces for instance) into each and every step of the integration architecture, the ESB makes it possible to interject common security, audit, or messaging tools. For instance, one could intercept all communications between certain sites to perform Security Assertion Markup Language (SAML) assertions, or enable 64-bit DES encryption at the enterprise level, rather than in each individual endpoint. Again, ESB allows for clean layering of responsibilities and delegation of specific tasks (such as security policies) to specialized applications.

Web services enablement of legacy data sources. Initially, ESB was not considered a solution for legacy integration. But now, it is widely accepted that legacy datasources have to be taken into account in an SOA—in fact, these datasources often make up most of the services involved.

Traditionally, accessing services in legacy applications such as ERP or CRM systems implied talking to the target system directly using the vendor protocol and APIs. (See Figure 3.) This means that teams building the service consumers have to be knowledgeable about the target system and compile the vendor API right in their clients (not to mention buying licenses for these APIs). The cost of deploying new service consumers is thus very high.

Figure 3 Accessing services (proprietary approach)

Most ESB vendors, however, provide adapters to connect to popular legacy systems. Accessing the services of your applications is then just a configuration matter, and the cost of adding new service consumers dramatically decreases—no need to speak the vendor protocols any longer, all that is required is standards (SOAP, JMS or any other entry point exposed by your ESB). (See Figure 4.)

Figure 4 Accessing services (standards-based approach)

With service virtualization in place, you can leverage an ESB to enable many scenarios. An example of this is multi-channel enablement. (See Figure 5.) Adding a new channel into a service that used to be solely accessible via a single API becomes a simple matter of configuration. And because the same single architecture is used to enable these multiple channels, it is possible to ensure that all accesses, no matter the channel, fall under a single global policy.

Figure 5 Multi-channel enablement

For example, by going through an ESB, a Web service that used to be accessible only from a customer portal over SOAP can allow other customer-facing systems, such as an IVR or fax gateway that might only talk JMS or DCOM, to access that same service.

The Science of Implementing an ESB

While many would consider developing a business-centric SOA an "art", the implementation of an ESB is much more of a science. Adherence to the proper methods, standards, and architectural principles will ensure a successful ESB implementation.

Implementing an ESB is often done in two workstreams; the software architecture and supporting infrastructure (or "Technical Architecture Workstream"); and the design, development, and deployment of the service logic (and supporting configurations) necessary to support the business (or "Application Architecture Workstream"). Let's take a look at both.

Technical Architecture Workstream. This workstream involves the selection of the software, identification of common architecture capabilities and infrastructure requirements, and the deployment of the overall foundational architecture upon which the services (and ultimately composite applications) can be developed. As with traditional projects, it is necessary to do a requirements analysis for the components of the technical architecture workstream. For this analysis, it is necessary to do a broad survey of the capabilities expected of the SOA, and decompose them into discrete services. A sample requirements list (non-exhaustive) could include:

• Error handling
• Auditing
• Policy management (to varying levels of detail)
• Service discovery
• Guaranteed delivery
• Protocol support (specific to applications & needs involved)
• Standards support (typically WS* standards, may include more depending on landscape)
• Intelligent routing

Only after you have identified these requirements and selected the product should development begin. Developer training may be more extensive given the intent on reuse that is a key focal point of all SOA implementations.

Application Architecture Workstream. The Application Architecture workstream involves the identification, design, creation, and deployment of business-level services to the bus. This particular workstream can be approached either top-down or bottom-up (as described previously); however, the underlying principles governing the actual design and development process vary only slightly depending on the approach.

Perhaps the first, and most crucial, decision when designing for an ESB is to identify the appropriate conditions under which a service should reside either on the bus or (for example) in a Business Process Management (BPM) tool. While on the surface these two capabilities may seem quite distinct, it is quite possible (and in some cases even preferable) to architect bus-like capabilities from a BPM tool. In general, the following guidelines apply here:

• Services on the ESB should be short-lived, discrete transactions.
  
  
• Services requiring sophisticated rules to determine routing, access, and other data-based decisions should reside on the ESB.
  
  
• Services that have end-point-specific logic should reside on the ESB. For instance, mapping canonical data objects to application-specific objects should be done in the bus when it cannot be done in the applications themselves (because you do not have control within that application, or perhaps because you do not have any COBOL programmers left around to make the modifications).
  
  
• ESB services should contain no human workflow activities.

Beyond these high-level guidelines, there are lower-level design and development guidelines that you should implement globally. Some of these guidelines are not unique to ESB, but are made more relevant as a result of ESB. We have indicated new ones below in italics.

• Establish metrics for success. At first glance this may seem obvious, but too often ESB (and SOA) projects fail because they are unable to quantifiably demonstrate success in the process or service they enabled. Useful metrics could include the number of consumers for a service and response time of a service (average and peak).
  
  
• For each application, the appropriate adapter must be identified, along with the corresponding protocols and enveloping technique that must be applied. This includes identification of any standards that are required in the interaction (WS-Reliable Messaging, for example). Be sure to consider transaction model (asynchronous or synchronous) as well as reliability needs when selecting the adapters and protocols.
  
  
• The source and target data objects involved must be defined, in detail, and mapped to the corresponding canonical object. If a canonical object does not exist, you must identify, design, and develop one. The existence of a canonical object is crucial to broad adoption of the ESB paradigm.
  
  
• Design metrics into the service. Leverage BAM tools to obtain easy access to real-time metrics. Examples for real-time metrics may include the number of orders over a given value, the number of customer updates to a certain type, or the number of requests made by a single person (customer or other) over time.
  
  
• Identify security restrictions at all levels. These levels include the application, transaction, data object content, and potentially data field content. Security policies must also be defined to support these requirements.
  
  
• Leverage existing services where possible. All enterprise-scale SOAs should have a searchable registry of services.
  
  
• Identify auditing requirements, as well as technical and business-level error handling requirements and design services accordingly. Some ESB tools have significant out-of-box capabilities to assist in this particular step.
  
  
• Design with all available standards in mind. It is good practice for the enterprise architecture group to publish the standards that will be supported in a given SOA environment, and to enable easy access to this list by all developers.
  
  
• When deploying the service, define and publish the WSDL. Register the service with the enterprise service registry.

Following these guidelines will result in a successful ESB implementation that will evolve easily with little change over time.

Additional Thoughts

Just like any other technology, an ESB comes with its own set of peculiarities and challenges. Here are some of the questions that you should expect to surface as you follow the ESB path.

• Preserving the separation of concerns that brought you to ESB in the first place. Your newly acquired ESB is a very powerful addition to your arsenal of technologies. It is a tool that often sports many of the features of its BPM cousins, such as logic constructs or transformation capabilities. While it might be tempting to use an ESB for some lightweight process orchestration, step back for a minute and think about why you brought an ESB into your SOA in the first place: to virtualize your IT infrastructure and separate business from IT concerns. So resist the temptation to leak some logic into your ESB; leave the choreography and process orchestration to BPM tools where they belong.
  
  
• Where to transform? With transformation capabilities present in most integration tools (messaging, ESB, BPM), the decision of "where" to transform "what" is no longer a tooling question but rather a best practice one. So what type of transformations should be done in an ESB vs. in a BPM tool? There is no one-size-fits-all answer here. A convenient rule of thumb is to extend the convenient "separation of concerns" principle to transformations, which would mean performing system-level, syntactic transformations (ex: CSV to XML) in ESB, while performing applications-level, semantic transformations (ex: CRM Customer to Canonical Customer) in BPM.
  
  
• Impact analysis. One challenge of loosely coupled architectures is to chart the relationships among services and assess the impact of changes or outages. Deriving direct as well as indirect dependencies can be a daunting task in large SOAs. By enabling greater decoupling, ESB can increase this problem. On the other hand, because it knows about all the services and their dependencies, an ESB is also the best source of information to perform a dependency analysis. This is an emerging field for integration vendors.
  
  
• Accepting the reality of heterogeneity (or "the fleet of buses"). While the picture-perfect ESB might a single logical, mono-vendor bus, one has to accept the reality of today's world: enterprises will have to deal with multiple buses, potentially from multiple vendors, across departments, locations, and time (through upgrades and migrations). With this in mind, it is important to adopt best practices and technologies that will make this reality easier to deal with. This is where the use of standards becomes crucial: HTTP, JMS or WS-RM for messaging, XSLT for transformations, WSDL for interfaces, and so on.

Conclusion

The ESB architectural pattern—and corresponding products—is a critical piece to any enterprise-scale SOA. The ESB provides a crucial function in disconnecting the application-specific logic from the BPM functions, while at the same time providing the vehicle to enable a loosely-coupled, virtualized service layer. With careful up-front architectural considerations, and ongoing rigor to enforce a set of straight-forward design guidelines, wiring services through an ESB becomes quite an industrialized science.

Brian Wilkinson is responsible for the Global Asset Development Program within Accenture's SOA Practice. He has implemented SOA and integration-related solutions at many of Accenture's most complex clients. Brian is Oracle Magazine's "SOA Architect of the Year" for 2006.

Demed L'Her is a Senior Principal Product Manager with Oracle, focusing on ESB and JMS. He has been involved in messaging and integration projects worldwide for 10 years.

Send us your comments