Enterprise Service Bus: Theory in Practice

2017-07-07 02:10:07

I often get asked for clarification on just what the differences are between ESB service containers, an application server container, and an integration broker. This section will point out the main differences.

6.7.1 Adherence to Standards

You can think of the contrast of an ESB versus an integration broker as highly distributed and standards-based versus centralized, monolithic, and proprietary.

A hub-and-spoke integration broker engine includes four main pieces of functionality: application adapters, data transformation, routing rules, and connectivity (Figure 6-17). Today's integration brokers were built when few standards were available to exploit, and are therefore largely proprietary. Also, as illustrated in Figure 6-17, some integration brokers have bolted on some standard interface technology, such as web services.

Figure 6-17. Hub-and-spoke integration brokers are centralized, monolithic, and largely proprietary; standard interfaces are an afterthought

An ESB makes prevalent use of standard interfaces and standard protocols throughout. Integration brokers have been largely proprietary, which, as discussed in Chapter 2, can carry a steep learning curve and result in vendor lock-in. Integration based on standards can provide a number of business benefits beyond just future-proofing your integration strategy. Chapter 3 discusses the benefits of adopting standards throughout your integration projects.

6.7.2 Centralized Hub-and-Spoke Processing

In a hub-and-spoke integration broker, the message payload must travel to the rules engine in the hub to perform data transformations and receive subsequent routing instructions (Figure 6-18). Also, each link into the hub potentially runs over a different protocol and transport, limiting reliability to the weakest link.

Figure 6-18. Hub-and-spoke integration brokers require that all messages return to the rules engine for further instruction after every step of processing

An ESB does not rely on any centralized processing engine, and lets the routing decisions occur at the remote nodes via itinerary-based routing. Hub-and-spoke has the advantage of centralized management and centralized control over routing and transformation rules. However, a good ESB should have a proper distributed management environment that allows remote containers to be updated with fresh information whenever necessary.

6.7.3 What's Hosted in the Container

To date, the main function of an application server has been to host business logic and to serve up web pages that are often based on dynamic content. Application server vendors trying to get into the integration business have been building integration broker capabilities on top of their application servers.

Both ESB containers and application server containers provide a managed environment for lifecycle issues, instance management, thread management, and timer services. Security and transaction services are also common in most application servers and ESBs.

An ESB service container is intended to host integration services and to execute business process flow logic, and host them only when and where you need them. For example, process flow logic can route an invoice to the proper financial system. Process flow logic can be specified declaratively or written as code in specialized services. Other examples of integration services include hosting an adapter or a content-based router.

Integration brokers, including those built upon an application server stack, require that the entire IB/appserver stack be installed everywhere you want integration broker functionality (Figure 6-19). Think of what it would mean to install an entire application server at a remote location simply so that it can host a JCA container, which hosts a JCA adapter, which acts as a conduit to an ERP system.

Figure 6-19. The "appservers everywhere" strategy

In contrast, with the ESB approach, integration broker capabilities are distributed across a more loosely coupled integration network as integration components that are independently deployed and managed (Figure 6-20). The only software component that needs to be installed at the remote location is the ESB service container. The ESB service container can act as a JCA container directly, without the rest of the appserver or integration broker stack, which in this scenario is just excess baggage. This is one of the business reasons why the ESB is changing the economics of integration. Licensing costs aside, the real cost of deploying application servers everywhere is in the installation, configuration, and ongoing operational overhead and cost of ownership over time.

Figure 6-20. Distributed service containers provide selective deployment of integration services that are independently scalable

6.7.4 Management Substrate

Managing an application server, even when using JMX, requires a direct connection between the management console and the remote JMX agent for the application server. In a highly distributed deployment, this separate management connection significantly increases the number of holes that have to be punched through the firewalls (Figure 6-21).

Figure 6-21. Managing application servers requires extra holes in firewalls

As we'll discuss in Chapter 10, ESB management traffic is designed to share the bus with application traffic, as illustrated in Figure 6-22. This means that the firewall configuration has to be done only once.

Figure 6-22. Remote management in an ESB requires no direct connection to each container, and no additional holes in the firewalls

6.7.5 Compiled Class Files Versus Declarative Rules

The main benefit of using XML standards (XPath, XSLT, XML DOM, and SAX) for transformation is that it makes the deployed processes much less brittle. For example, as shown in Figure 6-23, an ESB transformation service can be configured and deployed, merely by supplying it with the scripts and parameters it needs to use, as XML documents that are read in from a directory cache. Once deployed, the implementation is remarkably resilient to change in the XML schema. In many cases, changes in the XML schema will not invalidate the XPath selections within the XSLT, and new attributes and elements are carried along by the existing XSL templates. Even if the XSL script does change, it is easily redeployed. More information on service reuse and redeployment can be found in Chapter 7.

Figure 6-23. Configurable deployment artifacts such as XPath and XSLT are insulated from changes in XML schema

In contrast, compiled classes such as XML beans introduce a dependency on the XML schema that obviates adaptation to change. As shown in Figure 6-24, the use of the schema to generate Java code sets in motion a chain of dependencies that must then be retraced every time the schema is modified. This is because schema elements must be bound to Java objects. The problem is further compounded if the transform in question is deployed in multiple locations.

Figure 6-24. Schema changes result in downstream dependencies that must then be retraced whenever the schema is modified

Table 6-1 summarizes the comparison between compiled code in an application server and the declarative functions that are inherent in an ESB.

Table 6-1. Compiled code in ESB and J2EE appserver
	J2EE appserver	ESB
Web client proxy	Session bean*	HTTP endpoint**
Process definition	Compiled class (JPD)^*	Process/itinerary^**
Deployment parameters	Bean descriptor^**	DS config params^**
Routing rules	Message bean^*	Routing rules^**
Web service call	WS proxy class^*	WS endpoint^**
Aggregation service	Custom service^*	Process JOIN^**
Logging service	Entity bean^*	XML service^**
Transformation	XML bean^*	Transform service^**
Custom service	EJBean^*	ESB service^*

* Compiled code

** Declarative artifact

A key point to note is that the use of dynamically configured parameters, declarative scripts, and other runtime artifacts serves to reduce the amount of compiled code in the system, as illustrated in Table 6-1. The end result is a more flexible, loosely coupled deployment.

6.7.6 Abandon Application Servers?

You shouldn't take this negatively if you are an adopter of J2EE application server technology. Application servers are an important part of an IT organization, and an ESB is designed to integrate with them very well. In Chapter 11, we'll see a portal application design pattern in which application servers are used for both the frontend web container display logic and the backend business logic. The ESB is used in the middle to connect the two, providing an integration weave into the rest of the corporate fabric that is not application server-based.