Service-oriented architectures represent an approach to distributed
computing that treats software resources as services available on a
network. Such architectures are nothing new; CORBA and DCOM are
familiar examples. However, these older examples of service orientation
suffered from a few difficult problems. First, they were tightly coupled,
which meant that both ends of each distributed computing link had to
agree on the details of the API (application program interface). A code
change to a COM (component object model) object, for example, required
corresponding changes to the code that accessed that object. Second,
such architectures were proprietary. Microsoft unabashedly controlled
DCOM, and although CORBA was ostensibly a standards-based effort, in
practice, implementing a CORBA architecture typically necessitated
working with a single vendor's implementation of the specification.

Web services improve upon these DCOM and CORBA weaknesses. What's
new about today's service-oriented architectures built with Web services is
that they are standards-based and loosely coupled. The reliance upon
universally accepted standards such as XML (extensible markup language)
and SOAP (simple object access protocol) provides broad interoperability
among different vendors' solutions, and loose coupling separates the
participants in distributed computing interactions, so that modifying the
interface of one participant in the exchange doesn't break the other. The
combination of these two core principles means that companies can
implement Web services without having any knowledge of the consumers
of those services, and vice versa. The service-oriented architectures
discussed in this article are the standards-based, loosely coupled kind,
which we'll refer to as "SOAs."

The power and flexibility that SOAs potentially offer the enterprise are
substantial. If an organization abstracts its IT infrastructure so that it
presents its functionality in the form of coarse-grained2 services that offer
clear business value, then the consumers of those services (whether they
are at the same company or one of that company's business partners) can
access them independent of the underlying technology that supports
them. Furthermore, if service consumers can discover and bind3 to
available services while they are active, then the IT infrastructure behind
those services can offer extraordinary flexibility to the businesses that
invoke them.

Achieving these levels of power and flexibility, however, is a difficult task
that requires a new approach to architecture: the practice of SOA -- in
other words, what service-oriented architects must do to build SOAs.