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.
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.
