Binildas A. Christudas

December 2007

Summary: An Enterprise Service Bus (ESB) can help you manage the complexity of interconnecting systems and services to allow seamless information flow. (10 printed pages)

Contents

Introduction: Service Network
Convergent Services: A Reality
Enterprise Service Bus (ESB): Service-Network Backbone
Conclusion
Critical-Thinking Questions
Further Study
Glossary
 

Introduction: Service Network

Water, water, everywhere,

And all the boards did shrink;

Water, water, everywhere,

Nor any drop to drink.

–Samuel Taylor Coleridge, The Rime of the Ancient Mariner (Part II)

Every IT department will have many systems and many project teams. Each system will require information from other systems, and, for that, those systems have to interoperate. A single system that operates in isolation is not enough for doing business.

"Integrated information" and "integrated access to integrated information" are two sides of the same coin. To accomplish these goals, each organization should aim to facilitate the creation of the "boundary-less organization." To integrate means to interconnect. If you have a network, you can, and will, interconnect. This is especially true for URL-addressable services. Are your URL spikes going to make a mesh, as shown in Figure 1?

Figure 1. Point-to-point interconnection complexity

The problem that you will face is that, as the number of nodes in your network increases over time (and it will), the topology of your network will eventually smoothen into a dense surface. In the end, you would be left with too many points of failure—unmanageable, and non-maintainable!

Convergent Services: A Reality

When I joined The Phone Company to provide architectural insights for their in-house projects running there, I glanced through the Statement of Requirements (SOR), which at first seemed like just another problem statement. I soon realized that I would need to reread a few sections; the document turned out to refer to hundreds of systems and applications, which ranged from simple, file-based, custom UI programs to heavy database-oriented business systems, and with service scopes that ranged from the single line of business to the enterprise. The supporting systems and infrastructure all had been used by employees and end users of the company for many years.

In addition to leasing services to their customers, The Phone Company took advantage of their communications network and leveraged their PSTN networks, Third-Generation (3G) and Fourth-Generation (4G) services, and even Internet Protocol Television (IPTV), to support their internal systems. Although they and their customers routinely used the more modern of these technologies, they could not throw away the older PSTN circuit-switched networks, because, apart from the traditional call-making, they were dependent on many other services, such as Voice over IP (VoIP), that remained integrated with the older PSTN systems in some way. Hmm. The Phone Company had been adding applications and services for years, but never reducing them. Let us now have a look at Figure 2, to see how this network had grown over the years.

Figure 2. Point-to-point integration

What you see in Figure 2 is typical of many networks in the services industry. Provisioning for each new service is often supported by dedicated applications. Each of these applications is specialized and optimized for one function alone, and each remains in silos over time. If, by any chance, we start interconnecting them, for an n-node system portfolio we need n2 – n communication channels to be defined for complete integration. Each channel must have adaptors to perform formatting and/or protocol conversions, to support information exchange between these interconnected but very different kinds of applications. The problem is that the number of communication channels and adaptors grows very quickly with each new service that is added to the system.

The Phone Company's junior and mid-level developers and engineers told me that they wanted to do "the right thing" with their systems. They wanted to integrate their specialized services through a yet-to-be-conceived-of SOA framework, deviating from the traditional hub-and-spoke (or HAS) EAI approach that had been used so far. For each new product, for each new company or technology set that they acquired, the developers and engineers wanted to remove redundant services and leverage the ones that they had already built for other purposes.

This approach would help The Phone Company to do service consolidation. In other words, existing infrastructure or technology could be used in multiple ways to deliver new value-added services to the end user, without having to grow the number of communication channels and adapters needlessly. I determined that The Phone Company's service network would have to be revamped to support an Enterprise Service Bus, or ESB, that would include hooks for the efficient addition and removal of application and services. Figure 3 depicts this desired state.

Figure 3. Service-network vision

That all sounded nice; but, as I implied, the developers and engineers had not actually thought out how they were going to implement their SOA framework. Against my recommendations, they were heavily promoting a ReST architecture style. Many of the technical folks had previously worked together at a company that had used a ReST approach to integrate with external systems. A ReST-based system is characterized as a collection of resources that are located by using the familiar URL addressing scheme. All of these resources are accessed through the familiar HTTP protocol by using the generic GET, POST, PUT, and DELETE verbs. For example, an external company might provide information about dual core processors as a single-page HTML resource. A client could access that resource by applying an HTTP GET to the URL:

http://www.Fabrikam.com/processor/DualCoreProcessors.html

 

This, in turn, would return the HTML representation of that resource (in this case, DualCoreProcessors.html). The reception of the representation, together with the manner in which it was received, would place the client application in some particular state. If the client clicked an embedded link from within DualCoreProcessors.html, a new resource would be accessed. Because the same HTTP verb (GET) would be reused, the client would be assumed to retain its original state. Thus, the client application would transfer its state between each resource representation. (The mixing of HTTP verbs—for instance, going between GET and DELETE—would force the client to change its state.)

ReST is amongst the best-described architectural styles, but it might not be the solution for every problem at hand. The engineers of The Phone Company fell in love with the idea of ReST, because of its conceptual simplicity; but, to them, "everything looked like a nail." While ReST might have a certain appeal for integrating together external services (for instance, integrating The Phone Company with non–Phone Company services), my experience told me that there would be serious consequences for using ReST internally, as the service network was scaled over time.

The problem would have been that an internal network of highly meshed HTTP connections would be difficult to manage from an operations perspective, because of the opaque nature of the HTTP transactions, as well as the fact that content from "broken" HTTP connections are unrecoverable. Root-cause analysis, for instance, would be inefficient (if not impossible), because data within active transactions could not be actively traced. (The engineers dismissed this problem by telling me how well a system of logs would help problem determination.)

Other problems could occur when HTTP connections "break," leaving financial transactions lost to Bit Heaven. (Again, logs would come to the rescue.) Their ReST solution sounded appealing on the surface, I told them, but the critical problem would be one of ongoing mesh management that included the update of format/protocol adaptors at either end of the connector spikes. Meshes even interconnect "hidden services," which are always an enemy to flexibility, because one cannot directly infer the effect of change to replace a service.

The small army of developers, engineers, and even budding architects did not agree with me. Even after I told them about other woes that they would face, including the need to create "shim nodes" whenever they refactor services (which would increase specialization granularity)—which would increase their management problems even further—they still did not agree with me. To them, the "simplicity" factor ruled their thought process. I did do some soul searching, and I tried hard to determine why I might have been wrong in this situation. After all, if so many people thought that I was wrong, perhaps I was! In the end, however, I think that the problem lay with the small army of developers, engineers, and aspiring architects.

You see, a few of them let it slip that they simply did not understand what an ESB actually was, how a proper one should function, and what the specific motivations for implementing such a style would be. One of them told me, very dismissively, "We are creating transaction-oriented services. I don't see why any of these should be message-based." What that person did not understand (nor want to understand, apparently) was that messaging technology is a great enabler for service integration. (Aircraft manufacturers institutionalized this lesson many years ago, through various ARINC standards.) Perhaps, that person simply could not appreciate the difference between traditional Message-Oriented Middleware (MOM) and ESB. Perhaps, that person was focused on the stereotype of a system of distributed, compiled MOM clients, written with proprietary APIs. Perhaps, that person could not imagine what advantages standards-based integration of services (and other related advantages of ESB) could bring to the table.

Enterprise Service Bus (ESB): Service-Network Backbone

Enterprise Service Bus (ESB) is the newest incarnation of many lines of Enterprise Application Integration (EAI) approaches, but it functions more at the service level than at the component, application, or system level. Components, applications, and systems are physical units that must be explicitly deployed, whereas services represent logical groupings of URL-addressable functionality that can be accessed from anywhere without the need for explicit deployment. The aim of ESB is to create new services through the logical configuration of existing services on the shared bus, instead of hand-coding these new services for each new use and deploying them wherever they are needed.

ESB differentiates from its EAI counterpart of hub-and-spoke architecture by providing a highly distributed integration environment that scales well across departmental or line-of-business unit boundaries. Request routing, process routing, format translation, protocol conversion, rules-engine processing, and so on are a few of the common functions that every enterprise-class service requires. In ESB architecture, we separate these out from business logic, and allow the message bus to handle them in standard ways. An ESB allows for distributed deployment of services, while enabling centralized management and monitoring.

As Figure 4 shows, at the heart of the ESB is a Normalized Message Router, or NMR. Any two components interconnect to each other through the NMR, which follows a standard protocol and format. Any messages that flow through the NMR too follow the standard format. Components need not connect to each other in a point-to-point fashion, but instead make a single connection to the bus. Thus, if n nodes are to be interconnected fully, in place of n2 – n nodes, for the case of point-to-point integration, we now need only 2n channels to be defined for complete integration in an ESB architecture.

Figure 4. A normalized message router in ESB

Services can be remote to the ESB, in which case we need a suitable "binding component" that is configured in the ESB and is analogous to a remote stub that points to a remote component in Java RMI or .NET Remoting. Thus, by using suitable bindings (which would be available through standard binding libraries), services that would normally speak HTTP, FTP, IIOP, or even file interaction can all interact with each other through the NMR. Services can even be deployed as part of the ESB infrastructure. These "service engines" could be used to expand the shared capabilities of the ESB itself. Service engines can provide:

· Multiple modes of exposure that use multiple transport protocols (for example, HTTP, SOAP, and JMS).

· Mediated request and response semantics that could synchronous calls to asynchronous, and vice versa.

· Aggregation of multiple fine-grained services into a single coarse-grained service.

· Service management, including versioning, auditing, and so on.

· Routing and translations following specific enterprise-integration patterns.

· "Plug-and-play" features that enable new services to be integrated rapidly, and at reduced cost.

· Service substitution that can allow for the real-time replacement of services, while leaving consumers unaffected.

Thus, ESB provides an autonomous, federated service-management and monitoring infrastructure. For a line of business with 200 systems, we could reduce the number of connections from 40,000 to 400 and still achieve complete logical interconnectivity. Because the bus by itself would be distributed, we could deploy, reconfigure, and upgrade services (or collections of services) to remote sites as a whole and in a federated manner.

The moment that made The Phone Company's developers, engineers, and budding architects the most happy was when they saw the pilot implementation with their own eyes. The pilot demonstrated the ease with which we could plug-in and play and substitute services while the ESB continued to run, and consumers and providers continued running their transactions.

Conclusion

Businesses expand by increasing their product and service catalogs, or by merging or acquiring other business. The activities bring more and more systems and services into the IT infrastructure. Traditional integration methods for connecting these services will not scale to provide fault-tolerant operation, nor can we manage the ever-increasing complexity of the interconnections. ESB is different from point-to-point and hub-and-spoke styles in that it allows service providers and consumers to connect to a bus by using a single protocol and format; the ESB will mediate and transform the information, so that any participating service can interconnect effectively with any other service.

Critical-Thinking Questions

· Is there any difference between an Enterprise Service Bus and an Enterprise Message Bus?

· Are there any real issues in today's hub-and-spoke integration architecture? If we were to replace the architecture with an ESB, how much of these issues would be solved?

· Can we buy an ESB from some market one fine morning that can then straightaway solve all our integration headaches?

Further Study

· Bakker, Loek. "Goodbye Hub-and-Spoke, Hello ESB? Integration Architecture with BizTalk 2004." .NET Developer's Journal. September 12, 2005.(Accessed January 24, 2007.)

· "BEA AquaLogic Product Family." BEA AquaLogic Web site. 2007. (Accessed January 24, 2007.)

· Chappell, David A. Enterprise Service Bus: Theory in Practice. Cambridge, MA: O'Reilly Media, Inc., 2004.

· Christudas, Binildas A. "Service Provisioning Through ESB." java.net. October 18, 2005. (Accessed January 24, 2007.)

· Fielding, Roy Thomas. "Architectural Styles and the Design of Network-Based Software Architectures." Dissertation (Ph.D.), University of California, Irvine. 2000. (Accessed January 24, 2007.)

· Gavin, Lee, et al. "An EAI Solution Using WebSphere Business Integration (V4.1)." IBM Redbooks. July 28, 2003. (Accessed January 24, 2007.)

· Keen, Martin, et al. "Patterns: Implementing an SOA Using an Enterprise Service Bus." IBM Redbooks. July 25, 2004. (Accessed January 24, 2007.)

· Keen, Martin, et al. "Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6." IBM Redbooks. June 6, 2005. (Accessed January 24, 2007.)

· Li, Sing. "Plug into JBI with ServiceMix." ITarchitect.co.uk Web site. November 27, 2005. (Accessed January 24, 2007.)

· Martinez,Frank. "Reliable Messaging in a Services Network." Enterprise Architect Web site. June 2, 2005. (Accessed January 24, 2007.)

· "Microsoft BizTalk Server 2006: Business Process Management (BPM)."Microsoft BizTalk Web site. 2007. (Accessed January 24, 2007.)

· "Mule: Open-Source ESB and Integration Platform." Mule Web site. 2007. (Accessed January 24, 2007.)

· "Patterns and Best Practices for Enterprise Integration." Enterprise Integration Patterns Web site. 2007. (Accessed January 24, 2007.)

· "Service-Oriented Business Integration." Java Technology and Business Integration Web site. 2007. (Accessed January 24, 2007.)

· "ServiceMix, an Open-Source Java ESB-Based JBI." Apache ServiceMix Web site. 2007. (Accessed January 24, 2007.)

· Van de Putte, Geert, et al. "Using Web Services for Business Integration." IBM Redbooks. April 14, 2004. (Accessed January 24, 2007.)

Glossary

ARINC—Aeronautical Radio, Incorporated. A leading provider of technical services to the aerospace industry since 1929, ARINC has provided the industry with a number of implementation standards that still are in use today.

EAI—Enterprise Application Integration. The use of software and computer-system architectural principles to integrate a set of enterprise computer applications.

ESB—Enterprise Service Bus. An architecture style that uses a common messaging bus to integrate enterprise computer applications.

HAS—Hub-and-spoke architecture, also called "Message Broker." Similar to point-to-point architecture, in that it provides a centralized hub (broker) to which all applications are connected through network "spokes."

MOM—Message-Oriented Middleware. An enterprise application-integration strategy that relies on a system of asynchronous message sharing, instead of the point-to-point, request/response style that is found in small-to-medium-size businesses.

NMR—The Normalized Message Router. The central message-delivery mechanism in the JBI-based ESB. Messages that flow through the NMR will have a normalized or standardized format.

PSTN—The Public Switched Telephone Network. The network of the world's public circuit-switched telephone networks.

Remoting—Microsoft's .NET Remoting. A Microsoft application-programming interface (API) that is used for interprocess communications, it was released in 2002 with the 1.0 version of .NET Framework.

ReST—ReST. A term that is used by Roy Thomas Fielding in his Ph.D. dissertation to describe an architecture style of networked systems, ReST is an acronym that stands for REpresentational State Transfer.

RMI—The Java Remote Method Invocation API, or Java RMI. A Java application-programming interface for performing the object equivalent of remote procedure calls.

SOA—Service-Oriented Architecture. Regarded as a style of information-systems architecture, SOA enables the creation of applications by combining loosely coupled and interoperable services.

About the author

Binildas A. Christudas is a systems architect for U.S.-based communication-service providers. He specializes in distributed computing and SOA in Java and .NET, and is currently working as Senior Technical Architect for Infosys (http://www.infosys.com/). Binil is a Sun Certified Programmer, Developer, Business Component Developer, and Enterprise Architect; Microsoft Certified Professional; and Open Group (TOGAF8) Certified Enterprise Architecture Practitioner. He spends his free time with Sowmya and Ann in " God's Own Country." Contact Binil at either biniljava@yahoo.co.in or binil_christudas@infosys.com.

 

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.