Enterprise service bus middleware opens communication between applications.
In the 16th century the English navy commonly used messages in bottles to send ashore information about enemy positions. Given the sensitive nature of this information, Queen Elizabeth I even created the official position of “Uncorker of Ocean Bottles.” Anyone else caught opening a bottled message faced the death penalty.
Obviously, technological advances have allowed maritime communication to become far more sophisticated these days. For example, enterprise service bus (ESB) middleware underpins an advanced tracking system the U.S. Coast Guard has been using since Jan. 1, 2009, to dramatically enhance maritime security.
The Long Range Identification and Tracking (LRIT) system parses more than 50 million high-frequency messages every day to keep tabs on every vessel in U.S. coastal waters that weighs more than 300 tons. At any given time, the LRIT system is monitoring about 6,000 ships that transmit messages from their transponders every three seconds. This messaging data is then routed into a variety of applications used to visually map and plot the courses of vessels.
ESB facilitates LRIT by using messaging to transport data between “loosely coupled” applications, which is essentially the same function the middleware serves in business applications. ESB helps organizations integrate their existing data and applications into new business systems, allowing them to design and build more flexible applications and more quickly react to changing market conditions.
Continued Growth Expected
One or more ESBs form the basis for almost all service-oriented architectures these days, and industry experts say the ESB market should experience strong growth in coming years due to the technology’s ability to provide a low-cost way of overcoming many interoperability problems. Forrester Research says the ESB market was growing at more than 10 percent annually before the financial meltdown of September 2008, driven largely by SOA adoption. As the economy rebounds, WinterGreen Research expects a three-fold growth in the market through 2013.
Large organizations frequently use hundreds of different applications, and getting them to work well together has always been a formidable task. Many organizations have an environment of disparate legacy systems, applications, processes and data sources, which commonly interact across a rat’s nest of interconnections that are poorly documented and expensive to maintain.
The ESB was created as a “lightweight” alternative to the more costly and complex Enterprise Application Integration (EAI) platform. ESBs typically use messaging technology combined with a services-oriented architecture, XML, Web services protocols and intelligent routing to tie together disparate systems. Because existing applications, services and other data sources need only to plug into the bus to communicate, an ESB eliminates the usual maze of application interconnections. ESBs can be installed without disrupting existing applications and processes, and since they represent a thinner layer of function, they can be swapped out for another product more easily than a comprehensive EAI application.
No Bottlenecks
ESBs differ from the traditional approaches to application integration in other ways. They are based on standards such as Web services messaging or the Java Message System (JMS), unlike traditional approaches that are proprietary and closed. ESBs also are massively distributed, utilizing the processing power of each connected node as opposed to traditional approaches that rely on central coordination and processing.
But the chief difference may be that ESBs don’t have the hub-and-spoke architecture utilized by application servers and traditional EAI products, which feed all messages through a proprietary central hub. The hub-and-spoke architecture can be a bottleneck for high data volumes, as well as a single point of failure.
Instead, ESBs allow applications to pass messages to each other over a shared, standards-based messaging network. It’s been likened to replacing the centralized rigidity of a railroad network with the autonomous fluidity of a road transport system.
Focus on Flexibility
The use of an ESB not only allows organizations to link older applications to newer, browser-based front ends designed for Web interaction, but the loosely coupled architecture of the ESB also allows for the easy creation and addition of newer applications and connections as business needs evolve. Most important, the ESB infrastructure provides flexibility. IT can add, delete, modify or enhance applications; reconfigure services; and more easily manage traffic flows throughout the enterprise. The focus is on flexible, open services — not proprietary software.
ESBs are all about integration, so it’s natural that ESB functionality is making its way into cloud services. As organizations incorporate more cloud-based services into their application architectures, they must find a way to integrate with their legacy on-premises systems behind the firewall. A multi-tenant ESB architecture can provide the “in-the-cloud” middleware for connecting in-house and hosted applications.
“Web developers today are increasingly focused on rapidly delivering applications with rich user functionality,” said Mark Driver, vice president and research director, Gartner. “As these Web applications increasingly need to connect with other applications, cloud-based services and back-end data sources, there is a gap that needs to be filled — and it makes sense that a new class of infrastructure would emerge to fill that gap.”
