API Design & Management

Artificial Intelligence (AI)

Big Data


Business Technology

Cloud Computing




Digital Transformation

Internet of Things (IoT)

Machine Learning


Robotic Process Automation (RPA)

Service Governance

Service Security

Service-Oriented Architecture (SOA)

Spanish Courses & Exams

Arcitura Patterns Site

Arcitura on YouTube

Arcitura on LinkedIn

Arcitura on Facebook

Arcitura on Twitter

Community Home

Arcitura Books Published by Pearson Education

Partner Program

Onsite / Online Exams

Onsite / Online Training

Trainer Development

Home Study Solutions

Contact Arcitura


Workshop Scheduler

Download Catalog (PDF)




Artificial Intelligence Specialist

Big Data Architect

Big Data Consultant

Big Data Engineer

Big Data Governance Specialist

Big Data Professional

Big Data Science Professional

Big Data Scientist

Blockchain Architect

Business Technology Professional

Cloud Architect

Cloud Governance Specialist

Cloud Professional

Cloud Security Specialist

Cloud Storage Specialist

Cloud Technology Professional

Cloud Virtualization Specialist

Containerization Architect

Cybersecurity Specialist

DevOps Specialist

Digital Transformation Data Science Professional

Digital Transformation Data Scientist

Digital Transformation Intelligent Automation Professional

Digital Transformation Intelligent Automation Specialist

Digital Transformation Security Professional

Digital Transformation Security Specialist

Digital Transformation Specialist

Digital Transformation Technology Architect

Digital Transformation Technology Professional

IoT Architect

Machine Learning Specialist

Microservice Architect

RPA Specialist

Service API Specialist

Service Governance Specialist

Service Security Specialist

Service Technology Consultant

SOA Analyst

SOA Architect

SOA Professional

Acclaim/Credly Badges

Pearson Vue Exams


The Pearson Digital Enterprise Series From Thomas Erl

Service-Oriented Architecture: Concepts, Technology, and Design

The following corrections apply to the 1st printing (2nd and higher printings contain these changes):
Grammar, Wording, and Formatting Corrections:
Page 9, bottom bullet list, first bullet
Instead of “client-service” it should be “client-server
Page 24, Section 2.2.4, first paragraph
Instead of “..becoming less acceptable.” it should be “…limiting its ability to remain competitive.
Page 30, missing paragraph
The following one sentence paragraph belongs at the end of this page: “The following three chapters lay the groundwork by establishing, on a high level, what SOA is, how it’s come to be, and the basic Web services technologies most commonly used for its implementation.
Page 35, second paragraph
The first sentence in this paragraph is incorrectly worded. It should read: “A service description in its most basic form establishes the name and location of the service, as well as its data exchange requirements.
Page 42, last paragraph
Missing comma. A comma belongs after ‘how’, as follows: “Later we explain how, by creating…
Page 43, second paragraph, last line
Instead of “…type systems…” it should be “…dependencies (such as type systems)…
Page 45, second paragraph, first line
Instead of “…an SOA…” it should be “…a service-oriented…
Page 45, second paragraph, last line
Append the last sentence with the following text: “.., and evolves the enterprise into one where traditional application boundaries begin to disappear.
Page 46, first paragraph, last sentence
Instead of “aspect” it should be “benefit“. Also, remove “this form of” from this sentence.
Page 52, last paragraph, first sentence and Page 54, Section 3.2.20, second paragraph, first sentence
Replace this sentence with the following: “SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains.
Page 53, second paragraph, first line
Add “and encapsulation” after “reuse
Page 525, Step 1, first paragraph
Replace the first paragraph with the following new (and better worded) paragraph: “Avoiding redundancy within application services can be more challenging than with other types of reusable services. Business services, for example, benefit from well documented business models that already provide a clear separation of logic. These documents typically don’t exist for application services, making it easy, especially in larger organizations, for redundant functionality to inadvertently emerge. Extra up-front research effort is therefore required to complete this step.
Page 551, first paragraph
Add the following sentence to the end of the first paragraph. “(If you are wondering why the choice indicator was not used with this schema, see the Case Study (Process Results) section.)
Page 555, first paragraph
Replace the first paragraph with the following new (and better worded) paragraph: “Those of you familiar with XSD may have noticed an opportunity to incorporate a choice construct within this schema. In the past, some middleware vendors have been slow to support more than the most rudimentary XSD features for use with WSDL. Schemas for externally accessible Web services therefore sometimes had to be over-simplified by avoiding key elements. Support has rapidly improved, but it is still advisable to confirm this support.
Content Corrections:
Page 88, last paragraph, last line and Page 89, Figure 4.2 and Page 89, Figure 4.2 Caption
Remove “client-server” after “single-tier” so that it reads: “…single-tier architecture…
Page 150, sentence after bullet list
Instead of “Figure 5.27 illustrates…” it should be “Figure 5.25 illustrates…
Page 414, Step 11
Instead of “…identified in Step 5…” it should be “…identified in Step 6…

The following changes apply to the 1st to 4th printings (5th and higher printings contain these changes):
Content Corrections:
page 366, Case Study section, first paragraph
The first sentence of the first paragraph should begin as follows: “A variation of the top-down approach (limited to a specific business domain) was used by TLS‘”
Plus, the following sentence should be removed: “They went through the process of defining a corporate ontology and then implementing the resulting vocabulary within their business models and their service designs.
page 535, Step 7
This section is actually not a step in the design process. It belongs in the Service Design Guidelines area at the end of Chapter 15 because it applies to the design of all service models. This is why this step is not represented in the diagram on page 523.
Page 632, Example 17.10
Instead of <wsp:ExactlyOne ID=”Invoice1″> <wsp:All>
it should be <wsp:ExactlyOne> <wsp:All ID=”Invoice1″>
Updates (revisions made to reflect industry changes):
page 371, Step 1
The following step description replaces the previous one: “This step essentially encompasses Steps 1, 2, and 3 from the top-down strategy described earlier in this chapter, except that areas of the enterprise for which service delivery is a priority are given immediate attention. After Step 2 has begun, Step 1 continues as an on-going effort to further achieve the enterprise-wide analysis goals generally associated with the top-down approach.
page 372, Step 3
The following sentence should be added after the sentence that ends with “described in Chapters 13 to 16” so that they are both part of the same paragraph: “The extent to which the Compose SOA part of this process is required depends on the extent to which it was already addressed in Step 1.
page 450-451, Step 1
The following step description replaces the previous one: “Before services can be developed, the underlying architecture needs to be well defined. As explained in Chapter 14, this stage ask us to formally define a standard set of service layers and then choose open technologies in support of those layers. When a top-down delivery strategy is employed, these tasks are generally completed well before service candidates are even created. However, with more tactical variations of the top-down and agile approaches being the most common forms of service delivery, technology composition of a service-oriented architecture often needs to be dealt with as part of the service-oriented design process.
page 476, Figure 14.1 Caption
The caption should read: “The most fundamental components of a Web services-based SOA.
Page 477, Figure 14.2 Caption
The caption should read: “Suggested steps for composing a preliminary SOA. As explained in Chapter 13, depending on the delivery strategy employed, the Compose SOA step can be part of a top-down analysis effort or it can be positioned as a preparatory stage within a service-oriented design process.
Page 518, Step 7
Instead of: “Step 7: Identify required processing” the title of this step should be: “Step 7: Identify other required services.
The SOA delivery strategies are periodically revisited and refined. A new version of the top-down delivery strategy is available in the following document:
SOA Top-Down Process v2a.pdf.

The content of this document replaces the following parts of Chapter 10, Section 10.2.1: Figure 10.2, Steps 1, 2, and 3
The service-oriented analysis, service modeling, and service-oriented design processes are periodically revisited and refined. New versions of the service-oriented analysis and service modeling processes are available in the following document:
SOA Analysis Processes v2a.pdf.

The content of this document replaces the following sections in the book: Chapter 11, Section 11.1 and Chapter 12, Section 12.1

The following changes apply to the 1st to 9th printings (10th and higher printings contain these changes):
Page 127, Business service model section
In the third line of the first paragraph, the word “fully” should be replaced with “ideally” and at the bottom of this section, the following text should be removed: “In this case the business service would act as a controller, composing utility application services. (The controller service model is explained shortly.)
Page 127, Utility service model section
Replace the first paragraph with the following text:
A service providing generic functionality usually not associated with business logic can be classified as a utility service.
Page 128, Controller service model section
The last item in the bulleted list should be removed (the one that reads “to support autonomy in other services“) and the following text should be added to the end of this section: “The controller service model represents a role a service assumes when one of its operations carries out logic that composes operations within other services.
Page 337, Application service layer section
Replace the first paragraph with the following text:
The application service layer intentionally abstracts non-business-related logic (logic that is not derived from an organization’s business models) into a set of services that can simply be referred to as application services (or utility services). Their purpose is to provide reusable functions that address cross-cutting concerns by representing common enterprise resources and capabilities.
Page 339, Application service layer section
The following text should be removed: “Typical examples of service models implemented as application services include the following: utility service (explained in Chapter 5), wrapper service (explained shortly)” and “Integration services often are implemented as controllers.

…and the following text should be added before the last paragraph: “You may have noticed that application services are very similar to the utility service model we explained in Chapter 5. In fact, you can easily rename the application service layer as the utility service layer. Another common term that is also used is infrastructure services (or the infrastructure service layer). You are encouraged to use whatever term best suits your naming conventions.
Page 341, Section 9.4 Business service layer
All three paragraphs following the Section 9.4 title should be replaced with the following text:
The business service layer represents a collection of services based on the business service model called business services. It is through this service layer that we can achieve a close alignment between an organization’s business and technology domains. Analysts, architects, and other IT professionals collaboratively complete a special analysis process through which each business service is assigned a functional context derived from one or more existing organizational business models or specifications. (For more information regarding service-oriented analysis, see Chapter 11.)
Page 342, Section 9.4 Business service layer
Replace the text after Figure 9.4 with the following text:
In most enterprises, designing a business service layer leads the creation of two common business models, each of which establishes its own sub-layer:

Replace the text in the Task-centric business service bullet item with the following text:
– Task-centric business service – A service that encapsulates business logic specific to a task or business process that involves two or more business entities. Task-centric business services generally have limited reuse potential and can be simply referred to as task services.

Replace the text in the Entity-centric business service bullet item with the following text:
– Entity-centric business service – A service that encapsulates processing logic associated with a specific business entity (such as an invoice or timesheet). Entity-centric services are useful for creating highly reusable and business process-agnostic services. Entity-centric business services can also be called business entity services or just entity services.
Page 344, Section 9.5 Orchestration service layer
Replace the last two sentences of the last paragraph with the following text:
Note that process services can also be referred to as orchestrated task services. This additional qualification simply communicates the nature of the task services implementation environment and also tends to imply that the service is capable of composing larger, long-running service activities. The orchestration service layer can also be called the parent business process layer (which may be easier for business analysts to understand). Feel free to use whatever terminology fits best with your current conventions.