Introducing Service-Oriented Architecture

Introducing Service-Oriented
Architecture
S
ervice-oriented architecture (SOA) represents a new and evolving model for building
distributed applications. Services are distributed components that provide well-defined inter-
faces that process and deliver XML messages. A service-based approach makes sense for
building solutions that cross organizational, departmental, and corporate domain bound-
aries. A business with multiple systems and applications on different platforms can use SOA
to build a loosely coupled integration solution that implements unified workflows.
Overview of Service-Oriented Architecture
The concept of services is familiar to anyone who shops online at an e-commerce web site.
Once you place your order, you have to supply your credit card information, which is typically
authorized and charged by an outside service vendor. Once the order has been committed,
the e-commerce company coordinates with a shipping service vendor to deliver your pur-
chase. E-commerce applications provide a perfect illustration of the need for an SOA. If the
credit card billing component is offline or unresponsive, you do not want the sales order
process to fail. Instead, you want the order to be collected and the billing operation to proceed
at a later time. Figure 1-1 provides a conceptual workflow for an e-commerce business that
uses multiple services to process orders.
Figure 1-1. Service-based workflow for an e-commerce business
1
CHAPTER 1
701xCH01.qxd 7/17/06 12:48 PM Page 1
SOA is like other distributed architectures in that it enables you to build applications that
use components across separate domain boundaries. SOA uses Web services as application
entry points, which are conceptually equivalent to the proxy and stub components of tradi-
tional component-based distributed systems, except that the interactions between the Web
service provider and the consumer are more loosely coupled.
SOA is also unique in that it incorporates those factors that are critically important to
business: service reliability, message integrity, transactional integrity, and message security. In
the real world, businesses cannot take a chance on services that may not successfully process

a request. It is a given that disparate systems may be up or down at various times, or that sys-
tems may differ in their responsiveness due to varying loads, but none of this is an excuse for
allowing service request messages to simply drop away into the void. Furthermore, there can
be no ambiguity as to how a service must be called. If a system publishes its capabilities as a
web-enabled service, it needs to clearly document how the service must be called.
SOA addresses many of the availability and scalability issues in today’s applications.
Most applications implement a rigid synchronous communication model with a linear work-
flow that is highly susceptible to failures at any point. SOA assumes that errors can and will
occur, so it implements strategies for handling them. For example, if a service fails to accept
a message request the first time, the architecture is designed to retry the delivery. And if the
service is entirely unavailable (which should never occur in a robust SOA), the architecture is
designed to avoid possible catastrophic failures that may disrupt the entire service request.
SOA improves reliability because temporary failure in one part of the workflow will not bring
down the entire business process.
In a broader sense, SOA represents a maturing process, that is, the “growing up” of Web
services and integration technologies. SOA recognizes that mission-critical systems built
on distributed technology must provide certain guarantees. They must ensure that service
requests will be routed correctly, that they will be answered in a timely fashion, and that they
will clearly publish their communication policies and interfaces.
In an SOA solution, the distributed application uses service components that reside in
separate domains. Service components operate inside their own trust boundary and encap-
sulate their own data. They are maintained and updated independently of, though loosely
coupled with, the applications that use them.
Figure 1-2 shows a conceptual SOA that summarizes the three main entities in a typical
SOA solution:
• Service providers
• Service consumers
• Service directories
The consumer can use the Universal Discovery, Description, and Integration (UDDI) reg-
istry to discover or reference the description of a service provider. Interestingly, in Figure 1-2,

Service Provider #1 references a service provider (Service Provider #2). In this role, Service
Provider #1 is equivalent to a service consumer and can reference the UDDI registry for infor-
mation about Service Provider #2.
CHAPTER 1
■
INTRODUCING SERVICE-ORIENTED ARCHITECTURE2
701xCH01.qxd 7/17/06 12:48 PM Page 2
Figure 1-2. Conceptual SOA solution
The communication between the services and the consumer is in the form of XML mes-
sages that are qualified according to defined XSD schemas. XML messages are discrete entities
that may be transported, rerouted, and referenced at any point along the business workflow.
Messages promote higher levels of reliability and scalability because they can be stored, and
the services that process the messages can append additional information, which provides for
a clear and unambiguous chain of custody across the business workflow. In addition, mes-
sages can be queued in the event that a service is temporarily unavailable or backlogged.
XML messages are unlike traditional remote procedure calls (RPCs), which do not provide
a discrete structure for encapsulating a method “request.” Traditional RPCs cannot typically
be cached or held in a queue to wait for a better time to service the request. Instead, tradi-
tional RPCs typically time out if the receiving component does not respond within the
expected length of time. In addition, RPCs are not qualified to a reference schema (although
they must conform to type libraries for custom data types). Here lies the first important
lesson for developing SOA solutions: the Web services in the solution must be designed to be
message-oriented rather than RPC-oriented. This topic is the exclusive focus of Chapter 3.
What Are Web Services, Really?
Many of us are so familiar with current Web services technology that we often do not stop to
think about what services really are. However, you will need to if you are going to fully under-
stand what makes SOA so significant. Let’s pull out four definitions that collectively describe
what services are:
• Services are autonomous components that process well-defined XML messages.
• Services provide a well-defined interface that is described by an XML-based document

called the Web Services Description Language (WSDL) document, otherwise known as
the WSDL contract. This documents the operations (methods) that the service supports,
including data type information and binding information for locating and communi-
cating with the Web service operations.
• Services provide endpoints that consumers and other services can bind to, based on
the service’s port address (typically a URL).
CHAPTER 1
■
INTRODUCING SERVICE-ORIENTED ARCHITECTURE 3
701xCH01.qxd 7/17/06 12:48 PM Page 3
• Services are analogous to traditional object-oriented (OO), type-based components in
that they provide a defined interface and they execute one or more operations. How-
ever, a key difference is that service consumers can flexibly bind to a service, whereas
OO component consumers must set more rigid references. Service consumers can
respond flexibly to changes in a service provider interface because it is easy to regen-
erate the proxy class using the updated WSDL document. However, if a traditional
component changes its interface, the consumer itself must be recompiled in order to
avoid type mismatch errors. Components are tightly integrated to their consumers and
can break them. Service consumers, however, do not have to recompile if their service
changes. Instead, they simply have to rebind to the updated WSDL document. This is
what is known as loose coupling, or loosely coupled services.
Of course, if the service drastically changes its method signatures, problems may result
in the consumer. For example, the consumer may not have the ability to supply new and
modified input parameters for the updated methods. But as with any kind of interface-based
programming, it is understood that you cannot make significant changes to an existing method
signature, especially in terms of dropping existing input parameters, or changing the type def-
initions for existing input or output parameters. In Web services terms, this extends to the
XML schema–based input and output messages that are exchanged by the service, as well
as to its supported operations. Just as with traditional components, services should ideally
remain backward-compatible as their interfaces evolve, although this is not a requirement as

it is for classic OO programming. Web services technically only need to honor their current
contract as documented by their WSDL document, which allows potential clients to dynami-
cally bind to the service using the latest contract interface. Still, it is a significant advantage
that service consumers are autonomous from the services that they consume. This promotes
better stability in the SOA solution as the member services evolve.
There are five important properties of services in contrast to traditional type-based
components:
Services are described by a WSDL contract, not by type libraries: The WSDL contract fully
describes every aspect of the service, including its operations, its types, and its binding
information. WSDL is fully described in Chapter 2. In this sense it is much more complete
than traditional type libraries.
Service descriptions can be easily extended: The WSDL contract is based on an extensible
document structure that readily incorporates additional information beyond the core
service description. For example, security and policy information may be stored within
the WSDL document as custom SOAP elements. In fact, all of the Web services enhance-
ments that implement SOA infrastructure support can be documented as custom SOAP
elements. At its most basic level, SOAP is a stateless, one-way messaging protocol. But it is
also highly extensible, which makes it an excellent medium for storing and transporting
Web service enhancement information.
Services provide a service guarantee: Traditional type definitions provide no guarantees.
They are what they are, and you simply use them. But what happens if the type definition
gets out of sync with the component it is supposed to describe? This happens all the time
in the COM+ world, which relies on the Windows registry to store associated references
CHAPTER 1
■
INTRODUCING SERVICE-ORIENTED ARCHITECTURE4
701xCH01.qxd 7/17/06 12:48 PM Page 4
between registered components and their type libraries. Every developer has experienced
so-called DLL Hell, in which successive installations and removals of upgraded compo-
nents cause incorrect type information to be retained in the registry. Technically, this is a

versioning problem. But in more general terms this example points to the fact that there
is no service guarantee in the world of type libraries. You just have to hope that the com-
ponent is registered with the correct type library.
Services, on the other hand, can implement a service guarantee in the form of a policy
description that is contained within the WSDL contract. So-called policy assertions are
published with the contract to describe what level of service the consumer can expect,
and how the service operations can be expected to respond. There are many advantages
to policy assertions, not the least of which is that you could implement code in your con-
sumer so that it will only work with a service that enforces a minimum policy guarantee.
Should this policy ever change, then your consumer is designed not to use the service any
longer. In a very sophisticated application, you could design your consumer to autodis-
cover an alternate service using the UDDI registry.
Services allow for things to go wrong: When you call a method on a traditional type-based
component, you are making a leap of faith that the call will execute successfully. The real-
ity is that the vast majority of calls do go through, creating a sense of complacency that
this is always the case. But in the service-oriented world, where the supporting infrastruc-
ture is vastly more intricate and decoupled, you cannot have such a high level of faith that
calls will always go through. Recall that XML messages are the gold currency of service
requests. Messages can experience trouble at many steps along the way. Trouble in the
transport channel can prevent them from being delivered. Trouble in the service’s server
or firewall can prevent the service from ever responding to a received message. Further-
more, messages may be tampered with, so that they are malformed or suspect when they
do reach their intended target.
SOA accommodates all of these many potential problems using a set of technologies that
maintain the integrity of a service request even if things go wrong along the way. These
include reliable messaging, transaction support, and authentication mechanisms to
ensure that only trusted parties are involved in the service request (including certificate-
based mechanisms).
Services provide flexible binding: Services fully describe themselves using the WSDL con-
tract. This information includes documentation of the service operations as well as data

type information, referenced by well-defined XML schemas. This enables clear and
unambiguous qualified references. The best part is that a consumer does not have to
have any prior knowledge of a data type, as long as its XML namespace is documented
by or referenced by the WSDL contract. For example, consider a consumer that calls a
stock quote service. This service provides a RequestQuote method that returns a
custom complex data type called Quote, which includes current and previous share
price information, as well as 52-week high and low values. The consumer has no
advanced knowledge of how the Quote data type is structured, but it does not need
to as long as it can reference the qualified associated XSD schema.
CHAPTER 1
■
INTRODUCING SERVICE-ORIENTED ARCHITECTURE 5
701xCH01.qxd 7/17/06 12:48 PM Page 5