Java Reference
In-Depth Information
Chapter 1. Introduction to SOA
Introduction
This chapter briefly introduces the landscape of service-oriented architecture (SOA) and illus-
trates some organizational challenges that SOA can precipitate. While you are likely familiar
with a variety of SOA definitions, the solutions outlined in this topic—and indeed, the con-
struction of the topic itself—are in some part predicated on a specific understanding of how
we define the various constituent parts of SOA.
Heterogeneity is a fact of life in the modern IT landscape. There are hundreds of programming
languages in the world, all used to write applications that populate the modern enterprise. So-
metimes you need these applications to talk to each other, which can become a tricky propos-
ition very quickly.
Aging systems written in languages with waning platform support must work in conjunction
with applications written in disparate modern languages. These systems may have many ap-
parent warts and wrinkles, and it may be tempting to simply rip out the systems and replace
them. This can be prohibitively expensive, however, and rarely goes as smoothly as origin-
ally envisioned. It can also make you very vulnerable from an operational standpoint. These
applications have stood the test of time. They have been vetted in the battlefield of daily use.
And while we would like for our systems to look as neat and tidy as possible, many times
what naive developers see as code sprawl is simply the reality of handling the many twists and
turns and exceptional cases that the real world demands our applications account for.
There certainly is plenty of bad code in the world that isn't worth saving. Many legacy applic-
ations were written with principles in mind that have since changed dramatically. Sometimes
well-intentioned programs are written in such a snaky way that it can be very difficult to re-
use them in other applications. But for those legacy applications that are mission-critical, that
serve as the backbone of an organization, there is a way to modernize, reuse, and enhance their
power.
By wrapping legacy systems with web services that operate within the supporting framework
of a service-oriented architecture, you buy yourself time. This extension of time comes in the
form of vendor neutrality, which allows you to defer migration decisions, or simply extend the
life of aging but otherwise solid software.
Mergers and acquisitions can very quickly create integration problems. Heterogeneous plat-
forms with potentially redundant or overlapping functionality can undermine the agility, re-
sponsiveness, and service delivery capability of an organization. In the web-based world of
