Getting Started with Service-

Oriented Architecture (SOA)

Terminology

Grace Lewis This white paper presents basic terminology related to Service-
Oriented Architecture (SOA).1 The goal of the paper is to establish a
baseline of terms for service-oriented systems.
September 2010
Service-Oriented Architecture and Service-Oriented Systems
Service-Oriented Architecture (SOA) is a way of designing, developing, deploy-
ing, and managing systems, in which
• Services provide reusable business functionality via well-defined interfaces.
• There is a clear separation between service interface and service implemen-
tation.
• Service consumers are built using functionality from available services.
Service-Oriented • An SOA infrastructure enables discovery, composition, and invocation of
services.
Architecture (SOA) is
• Protocols are predominantly, but not exclusively, message-based document
a way of designing, exchanges.
developing, From a more technical point of view, SOA is an architectural style or design pa-
deploying, and radigm; it is neither a system architecture nor a complete system. Systems that
are built based on the SOA characteristics listed above are called service-
managing systems … oriented systems. A high-level view of a service-oriented system is presented in
it is neither a system Figure 1.
architecture nor a
Services
complete system. Services are reusable components that represent business or operational tasks,
such as customer lookup, credit card validation, weather lookup, or line-of-sight
calculation. Reusable is a key element of this definition because it is what
enables the creation of new business and operational processes based on these
services. Services expose their capabilities via well-defined, standard service
interfaces. In a service-oriented environment, service interface definitions are
Software Engineering Institute available in some form of service registry.
Carnegie Mellon University
4500 Fifth Avenue
____________________________________________________________________________
Pittsburgh, PA 15213-2612
1
The basic terminology has been extracted from the SEI course Service-Oriented Architec-
Phone: 412-268-5800 ture: Best Practices for Successful Adoption. For more information about the course, visit
Toll-free: 1-888-201-4479 http://www.sei.cmu.edu/training/p81.cfm.
www.sei.cmu.edu

Toll-free: 1-888-201-4479
 End User Internal External
Portal
Application System Consumer

Service Consumers

SOA Infrastructure Internet

Data
Security Discovery
Transformation
Infrastructure

Service Service Service Service

A B C D

Service Interfaces

Enterprise Legacy or New External

Information System Service Code System Service
Internal Users Implementation

Figure 1: High-Level View of a Service-Oriented System

The service implementation corresponds to the actual system capabilities that

implement the service interface. Service implementations typically reside in en-
terprise information systems, such as ERP (Enterprise Resource Planning) sys-
tems; in legacy or new service code built specifically to provide service capabili-
ties; or in external systems. This separation between service interface and service
implementation is what allows platform independence—service consumers
access the services via standardized service interfaces that hide the complexity
and diversity of service implementations from consumers. The organization that
hosts a service implementation is referred to as the service provider.

SOA Infrastructure
The elements of a An SOA infrastructure is the set of technologies that bind service consumers to
service-oriented services through an agreed-upon communication model, such as one based on
Web Services, message-oriented middleware (MOM), publish/subscribe, or
system are services, Common Object Request Broker Architecture (CORBA). In addition, SOA in-
service consumers, frastructures typically host infrastructure services that can be used by service
and the SOA providers and service consumers to perform common tasks or satisfy quality
attribute requirements of the environment. Typical infrastructure services include
infrastructure that security, discovery, and data transformation.
binds service
Service Consumers
consumers to
Service consumers are the clients for the functionality provided by the services.
services. Examples of service consumers are end-user applications, internal systems, ex-
ternal systems, and composite services. Consumers programmatically bind to
services (i.e., there is a piece of code running on the consumer side that invokes
a piece of code running on the provider side that corresponds to the service inter-
face).

1 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY
 Three Basic Operations to Support Service-Oriented Systems
The SOA infrastructure enables the three basic operations to support service-
oriented systems: service discovery, service composition, and service invocation.

Service Discovery
Service discovery is the mechanism by which service consumers become aware
of available services and their capabilities. Service discovery starts with a one-
time operation in which the service provider publishes its service in some form
of service registry. The form of registry can range from a simple web page to a
robust implementation with advanced query capabilities. The service registry is
then queried at design time by the developers of service consumers for services
with desired capabilities.

Even though there is much discussion about runtime discovery of services, the
Even though there is
reality is that current technologies do not support runtime discovery. The word
much discussion dynamic is often used to describe the binding between service consumers and
about runtime services. There are various degrees of dynamism. At the lower end of the spec-
trum is late binding of a proxy service to a specific service instance that depends
discovery of services,
on user context or load-balancing policies. At the higher end of the spectrum is
the reality is that fully dynamic binding in which service consumers are capable of querying ser-
current technologies vice registries at runtime, selecting the “best” service from the list of returned
services, and invoking the selected service—all at runtime, and without human
do not support intervention. Late binding is a common, out-of-the-box feature of many com-
runtime discovery. mercial and open-source SOA infrastructures. Fully dynamic binding, on the
other hand, requires semantically described services that use an ontology that is
shared between service consumers and service providers. Semantic Web Servic-
es represent an active area of research, as well as an unsolved problem that is not
yet ready for large-scale deployment.

Service Composition
Service composition is the mechanism by which services are combined to fulfill
a business or operational process. Service composition can be done fully within
the service consumer, but there is also considerable support for service composi-
tion within SOA infrastructures, specifically in Business Process Modeling
(BPM) infrastructure components. Typical BPM components enable a service
consumer developer to graphically compose services available in a registry and
then generate the appropriate code for the orchestration.

Service Invocation
Service invocation is the mechanism by which services are invoked by service
consumers at runtime. There are two basic invocation patterns: point-to-point
and mediated.

2 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY
 In the point-to-point invocation pattern, service consumers directly invoke ser-
vices over a network. Point-to-point is most acceptable in environments that are
small in number of services and consumers, homogenous in implementation
technologies, and have low pace of change (business and technology).

In the mediated pattern, service consumers invoke services via a middleware

component such as an Enterprise Service Bus (ESB). The mediated pattern is
most acceptable in environments that are large in number of services and con-
sumers, technologically diverse and rapidly changing.

Web Services
Web Services is one technology pattern for implementing service-oriented sys-
Because it is the tems, as shown in Figure 2. Because it is the most common technology pattern,
Web Services is often equated to SOA. Initially, Web Services were commonly
most common implemented using the WS* stack. More recently, an alternative called REpre-
technology pattern, sentational State Transfer (REST) has surfaced and is being widely adopted.
Web Services is often
Class of System Distributed Systems
equated to SOA.
Initially, Web Services
Architecture Service-Oriented Peer-to-Peer
were commonly Pattern Systems Systems ….
implemented using
the WS* stack. In the Technology
Pattern Web Services Broker Architecture ….
last several years, an
alternative called
REST has surfaced Implementation WS*Web Services RESTful Web Services CORBA

and is being widely Implemented using

adopted. Figure 2: Web Services in the Context of Distributed Systems

WS* Web Services

In the simplest implementation of WS* Web Services
• Service interfaces are described using Web Services Description Language
(WSDL).
• Data is transmitted using SOAP over HTTP.
• There is a way for service consumers to discover services and obtain infor-
mation of how to bind to them, such as UDDI-based registries, database-
based service registries, web pages, or wikis.
In a traditional request-response implementation of WS* Web Services, a service
request is formed as an XML document according to the WSDL documentation
of the service and bundled in a SOAP message that is transported via HTTP. The

3 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY
 service request is parsed and processed appropriately by the service provider,
which then sends back a service response that is also an XML document formed
according to the service’s WSDL document and processed in the same way.

In addition to these base standards, there are many additional standards that deal
Even though the
with aspects such as service orchestration and choreography, as well as the sup-
number changes port for cross-cutting quality attributes, as shown in Figure 3. Even though the
frequently, there are number changes frequently, there are currently over 100 WS* standards. In Fig-
ure 3, standards names in green mean that the standard is fairly stable, yellow-
currently orange means that it is becoming the standard, and red means that work on the
approximately 100 standard has stopped but the standard is still used.
WS* standards.
Orchestration and
Choreography
WSCL, WSCI, BPEL,
WS-Coordination,
BPML, BPSS

Quality of Service
Discovery

Management
Transactions
UDDI

Security
Description
WSDL
Message Format
Base SOAP
Stack
Encoding
XML
Transport
HTTP
Ada pted from “XML and Web Servi ces Unleashed,” SAMS Publishing

Figure 3: WS* Protocol Stack

A problem in WS* Services is that most of the standards related to the cross-
cutting quality attributes are still emerging and even competing. This means that
standards for implementing higher levels or cross-cutting aspects of the protocol
stack require careful evaluation and selection.

Another aspect that is worth mentioning is that interoperability needs agreement

on both syntax and semantics. WS* Web Services enable syntactic interoperabil-
ity but do not guarantee semantic interoperability. Even though XML Schema

4 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY
defines structure and data types and WSDL defines the service interfaces (opera-
tions, parameters, and return values), XML and WSDL do not define the mean-
ing of data and WSDL does not define what a service does.

From an implementation perspective, what all this means is that systems that
implement the WS* base stack are highly interoperable at the syntactic level, but
this is not a guarantee for systems that implement higher levels or cross-cutting
aspects of the protocol stack. Also, higher levels of interoperability such as se-
mantic interoperability have to be built into the system through the use of data
models or ontologies that describe the data that is being exchanged.

RESTful Web Services

REST provides a much simpler implementation of Web Services. In the REST
implementation of Web Services, every entity that can be identified, named, or
handled is considered a resource that is addressable by using a universal syntax
(i.e., Universal Resource Identifier—URI). Consumers communicate with ser-
vices using basic HTTP operations: GET, POST, PUT, and DELETE.

The main strength of RESTful Web Services is their simplicity: the request is a
simple HTTP operation and the response is plain XML text embedded in an
HTTP response. However, in REST there are no standards to support quality
attributes, other than the basics (e.g., transport-level security using HTTPS). This
means that REST may not be appropriate in environments with demanding quali-
ty attribute requirements.

WS* vs. REST

Web Services are commonly implemented using the WS* stack, but REST is
starting to be widely adopted. The decision to implement WS* or REST will
depend mainly on system quality attributes requirements. WS* implementation
has greater support for security, availability, transaction management, etc.
RESTful implementations, because of their simplicity, are more appropriate for
read-only capabilities, typical of mashups, where there are minimal quality
attribute requirements and concerns.

Enterprise Service Bus (ESB)

An Enterprise Service Bus (ESB) is a “middleware product that connects and
mediates all communications and interactions between service consumers and
services, usually based on standards.”2 Even though an ESB is not required to
implement a service-oriented system, it is useful in large, heterogeneous service-
oriented environments because it reduces the complexity of connecting services

____________________________________________________________________________
2
Definition from Wikipedia: http://en.wikipedia.org/wiki/Enterprise_service_bus

5 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY
with their consumers by implementing the VETRO pattern,3 as shown in Figure
4.

XML Verify that it is Add Convert Route Invoke the

Document a well-formed additional message to a message target service
XML data to the target format based on or interact in
Example
document and message to content or some way with
conforms to a make it more environment the target
particular meaningful conditions system
schema or and useful to
WSDL a target
document that service or
describes the system
message.

Figure 4: The VETRO Pattern

The implementation of the VETRO pattern is the way that the ESB manages as-
pects such as interface compatibility, service versioning, service routing, and
data transformations. In essence, an ESB handles many of the potential incompa-
tibilities between service consumers and services and provides elements to guar-
antee quality attribute requirements such as routing based on load balancing to
promote performance and availability.

Another important component of an ESB is the service registry. As mentioned

previously, the registry contains metadata about services that have been regis-
tered by their providers and are available for use. At a minimum, the registry
contains the specification (or contract) for using the service (e.g., the WSDL
document in the case of WS* Web Services). However, a registry can be confi-
gured to capture additional information that can be used in queries, such as
• Description
• Classification
• Usage history
• Test cases and test results
• Quality attribute metrics
• Additional documentation
A registry can also help keep track of service consumers. This is useful to under-
stand required service levels, facilitate change impact analysis, and notify con-
sumers of service changes.

____________________________________________________________________________
3
Source: Dave Chappell, Enterprise Service Bus (O’Reilly, 2004, ISBN 0-596-00675-6)

6 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY
Summary
SOA is currently the best option available for systems integration and the leve-
raging of legacy systems. Technologies to implement service-oriented systems
will certainly evolve to address emerging needs, but the concepts will remain. It
is important to have a common SOA terminology and create a baseline for ac-
tivities such as
• evaluating technologies in their context of use
• selecting technologies based on their relationship to business and operational
goals
• understanding situations in which a service-oriented approach is appropriate
and situations in which it is not
• analyzing service-oriented systems from the perspective of the service con-
sumer, the service provider, and the SOA infrastructure
• understanding which parts of the system will come “out-of-the box” and
which will have to be built

Resources
• Learn about SOA through SEI courses. For more information, visit
http://www.sei.cmu.edu/go/soaofferings/index.cfm.
• Explore SEI SOA reports, webinars, podcasts, and presentations. For more
information, visit http://www.sei.cmu.edu/library/abstracts/soa/.
• For information on SEI products and services, write to info@sei.cmu.edu.

Copyright 2010 Carnegie Mellon University.

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE

MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES
NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER
INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE
MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY
KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT
INFRINGEMENT.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark
holder.

Internal use. Permission to reproduce this document and to prepare derivative works from this document
for internal use is granted, provided the copyright and “No Warranty” statements are included with all
reproductions and derivative works.

External use. Requests for permission to reproduce this document or prepare derivative works of this
document for external and commercial use should be directed to permission@sei.cmu.edu.

This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003
with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally
funded research and development center. The Government of the United States has a royalty-free govern-
ment-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to
have or permit others to do so, for government purposes pursuant to the copyright license under the clause
at 252.227-7013.

7 | GETTING STARTED WITH SERVICE-ORIENTED ARCHITECTURE (SOA)

TERMINOLOGY