Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

JVM Languages

Defining the ESB



Eric is a DDJ contributing editor and consultant in New York. He has worked extensively in Java and C++ developing real-time trading and financial applications and is the author of Java Messaging. He can be contacted at [email protected].


The combination of low-cost computing, fast networks, and, of course, the Internet, has driven software beyond the boundaries of a single computer. Almost all of today's enterprise software applications are built and deployed as distributed components, which can be spread across computers, networks, and entire corporations. A single user request may interact with a global set of computers and networks, each owned by different companies around the globe, before a response is assembled and delivered back to the user.

This may be obvious. However, what is less obvious are the solutions to the challenges that distributed software development create. In this article, I guide you through a solution-set to these challenges, using a relatively new piece of software, called the "Enterprise Service Bus" (ESB).

The Distributed Software Challenges

When you design enterprise software with an architecture that includes decoupled components, you enable an iterative software development and deployment process which results in systems that grow efficiently, and scale economically. The cost of developing and maintaining the software is spread across time, and shared across organizations. As usage of the software grows, parts of the software deployment can grow with it. Figure 1 shows an enterprise software application that is deployed across a varied number of servers within separate organizations. Servers can be added, on demand, as usage grows, and can be limited to the areas of greater usage.

Figure 1: An enterprise application with distributed components is better positioned for growth, and enables resource sharing within and across organizations.

However, these advantages -- scalability, shared resources, and shared costs -- come with their own challenges, especially when the software is developed without a unified architecture. Some of these challenges are:

  • Increased complexity
  • The need for greater security
  • System reliability

These challenges are amplified when some of the components are built by different development groups, or different organizations. Such disparate, and hence disjointed, systems usually require more effort, time, and money to deploy and maintain. Before examining possible solutions, let's look at these challenges a little more closely.

The Complexity Challenge

Complexity in distributed software systems comes in the form of touch-points, or lines of communication, between different pieces of the software. As components are spread out across computers and networks, dependencies are built between those components, computers, and networks. If a software component is moved to reside on a different computer, or if a computer is moved onto a different network, or if the network architecture is modified in any way, there may be a rippling affect across the associated distributed applications.

When these changes do occur, the result may be as subtle as unexplained application behavior, or as bad as a completely broken application. Care must be taken to reduce these types of dependencies, and to minimize the effects when changes are made.

The Security Challenge

When distributed components communicate over a network, there is a potential for that communication to be tapped into, or otherwise spoofed. The potential for trouble increases when this communication spans networks, organizations, and the Internet. Malicious software, or people, may snoop network activity to retrieve sensitive data, especially those involving financial transactions.

Standards and measures for security must be implemented at every leg of the distributed application, and it must be done consistently across all of the organizations that the application spans. This level of coordination can be a huge challenge within one organization, never mind other (possibly competitive) organizations.

The Reliability Challenge

Simply put, the more computers involved in processing a user request, the greater the chance a failure will occur. Redundancy and failover strategies must be put in place in all areas of the application, but this may be implemented differently depending on the part of the application in question. For example, each network component may be paired with a redundant component; web servers may be deployed in farms of hundreds or even thousands of servers; application servers may be clustered in smaller numbers of servers; and database systems may be replicated across datacenters.

By far the most challenging of the reliability issues will be those that involve software communication. It's vital that when a component makes a request to another component, the response should arrive accurately and in a timely manner. The proper mechanisms must be in place to ensure that messages are re-sent when they are lost, and that they arrive in the same form as when they were sent, even if they are sent over foreign or unreliable networks.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.