my Summary of Service-Oriented Architecture (SOA): Concepts, Technology, and Design by thomas erl summarized by Mohammed Omar

1. 1
Summary of Service-Oriented
Architecture (SOA): Concepts,
Technology, and Design
P a r t 1 c h - 1 t o 5
B y M o h a m m e d O m a r
, P M P , T O G A F , C I S A , I T I L
19-Sep-2013
These notes, extracts and
excerpts are from Thomas Erl
famous book
Architecture (SOA): Concepts,
Technology, and Design

2. 2
Chapters 1-5
Standards" vs. "Specifications" vs. "Extensions"
Standard An accepted industry standard.
Specification Describes the standard
Extension represents a feature provided by the specification.
starting with an XML foundation architecture not web-service
SOA and web services
SOA is an architecture design that could be realized. Through any
Suitable technology platform such as web services
SOA is the specification. And web services is the realizing
technology
I Primitive SOA
The primitive SOA. It is labeled as such because it represents a
baseline technology architecture that is supported by current major
vendor platforms
1-How services encapsulate logic
To retain their independence, services encapsulate logic within a
distinct context. This context can be specific to a business task, a
business entity, or some other logical grouping.
service logic can encompass the logic provided by other services.
In this case, one or more services are composed into a collective

3. 3
when building an automation solution consisting of services, each
service can encapsulate
- a task performed by an individual step or
- a sub-process comprised of a set of steps.
- And even encapsulate the entire process logic.
In the latter two cases, the larger scope represented by the services
may encompass the logic encapsulated by other services.
2-How services relate
based on an understanding that for services to interact, they must
be aware of each other. This awareness is achieved through the use
of service descriptions.
A service description in its most basic format establishes the name
of the service and the data expected and returned by the service.
The manner in which services use service descriptions results in a
relationship classified as loosly coupled or messaging
3-How services communicate
After a service sends a message it loses control of what happens to
the message That is why we require messages to exist as
"independent units of communication." This means that messages,
like services, should be autonomous. To that effect, messages can
be outfitted with enough intelligence to self-govern their parts of
the processing logic ( self governing message)
4-How services are designed

4. 4
Key design principles are
- Loose coupling Services maintain a relationship that minimizes
dependenc
- Service contract Services adhere to a communications agreement,
as defined collectively by one or more service descriptions and
related documents.
- Autonomy Services have control over the logic they encapsulate.
- Abstraction Beyond what is described in the service contract,
services hide logic from the outside world.
- Reusability Logic is divided into services with the intention of
promoting reuse.
- Composability Collections of services can be coordinated and
assembled to form composite services.
- Statelessness Services minimize retaining information specific to
an activity.
- Discoverability Services are designed to be outwardly descriptive
so that they can be found and assessed via available discovery
mechanisms
Common characteristics of contemporary SOA
Contemporary SOA builds upon the primitive SOA model by
leveraging industry and technology advancements to further its
original ideals. Though the required implementation technology
can vary.
1-SOA increases quality of service
To bring SOA to a point where it can implement enterprise-level
functionality as safely and reliably as the more established
distributed architectures already do it must adhere to common
quality of service requirements

5. 5
- The ability for tasks to be carried out in a secure
manner,protecting the contents of a message, as well as access to
individual services.
- Allowing tasks to be carried out reliably so that message delivery
or notification of failed delivery can be guaranteed.
- Performance requirements to ensure that the overhead imposed
by SOAP message and XML content processing does not inhibit
the execution of a task.
- Transactional capabilities to protect the integrity of specific
business tasks.
2-SOA is fundamentally autonomous
individual services must be as independent and self-contained as
possible with respect to the control they maintain over their
underlying logic. This is further realized through message-level
autonomy where messages passed between services are sufficiently
intelligence-heavy that they can control the manner in which they
are processed by recipient services.
3-based on open standards
(open, vendor-neutral communications framework)
the message itself is standardized, both in format and in how it
represents its payload. The use of SOAP, WSDL, XML, and XML
Schema
After a message is sent from one Web service to another it travels
via a set of protocols that is globally standardized and accepted
4-SOA supports vendor diversity
The open communications framework allows organizations to
choose best-of-breed environments for specific applications as
long as it supports the creation of standard Web services, it can be
used to create a non-proprietary service interface layer, opening up
interoperability opportunities with other, service-capable
applications . This, incidentally, has changed the face of integration
architectures, which now can encapsulate legacy logic through

6. 6
service adapters, and leverage middleware advancements based on
Web services.
5-promotes discovery
SOA supports and encourages the advertisement and discovery of
services SOA will likely rely on some form of service registry or
directory to manage service descriptions
In the early days of services discovery was not adopted by
because When utilized within traditional distributed architectures,
Web services were more often employed to facilitate point-to-point
solution
6- promotes federation
the ability to encapsulate legacy and non-legacy application logic
and by exposing it via a common, open, and standardized
communications framework By extensive adapter technology
marketplace
6-SOA promotes architectural composability
Composability is a deep-rooted characteristic of SOA that can be
realized on different levels
As previously mentioned, services exist as independent units of
logic. A business process can therefore be broken down into a
series of services, each responsible for executing a portion of the
process.
A broader example of composability is represented by the second-
generation Web services framework that is evolving out of the
release of the numerous WS-* specifications. The modular nature
of these specifications allows an SOA to be composed of only the
functional building blocks it requires.
Because Web services specifications are being designed
specifically to leverage the SOAP messaging model. Individual
specifications consist of modular extensions that provide one or
more specific features. As the offering of WS-* extensions

7. 7
supported by a given vendor platform grows, the flexibility to
compose allows you to continue building solutions that only
implement the features you actually need In other words, the WS-*
platform allows for the creation of streamlined and optimized
service-oriented architectures, applications, services, and even
messages.
7-SOA emphasizes extensibility
When expressing encapsulated functionality through a service
description, SOA encourages you to think beyond immediate,
point-to-point communication requirements. When service logic is
properly partitioned via an appropriate level of interface
granularity, the scope of functionality offered by a service can
sometimes be extended without breaking the established interface
8- SOA adopt intrinsic interoperability
Using of open standards, a vendor diverse environment, and the
availability of a discovery mechanism, is the concept of intrinsic
interoperability. When building an SOA application from the
ground up, services with intrinsic interoperability become potential
integration endpoints When properly standardized, this leads to
service-oriented integration architectures wherein solutions
themselves achieve a level of intrinsic interoperability.
9-SOA implements layers of abstraction
SOAs can introduce layers of abstraction by positioning services
as the sole access .by establishing a layer of endpoints that
represent entire solutions and technology platforms, all of the
proprietary details associated with these environments disappear
The only remaining concern is the functionality offered via the
service interfaces
10-SOA promotes loose coupling throughout the enterprise

8. 8
building a technical architecture with loosely coupled services is
the resulting independence of service logic. Services only require
an awareness of each other, allowing them to evolve independently
By implementing standardized service abstraction layers, a loosely
coupled relationship also can be achieved between the business
and application technology domains of an enterprise
Each end only requires an awareness of the other, therefore
allowing each domain to evolve more independently. The result is
an environment that can better accommodate business and
technology-related changea quality known as organizational agility
11-SOA promotes organizational agility
Business agility and flexibility is the aim of most enterprises today
and that must be secured by IT Divisions ,organization's ability to
accommodate change determines the efficiency with which it can
respond to unplanned events.
By leveraging service business representation, service abstraction,
and the loose coupling between business and application logic
provided through the use of service layers, SOA offers the
potential to increase organizational agility
Defining SOA
SOA represents an open, agile, extensible, federated, compostable
architecture comprised of autonomous, QoS-capable, vendor
diverse, interoperable, discoverable, and reusable services ,
implemented as Web services
“Common tangible benefits of SOA”
- “Improved integration (and intrinsic interoperability)”
- Inherent reuse
- “Streamlined architectures and solutions”
- “Realizing this benefit requires adherence to design standards
that govern allowable extensions within each application

9. 9
environment. Benefits of streamlined solutions and architectures
include the potential for reduced processing overhead and reduced
skill-set requirements (because technical resources require only the
knowledge of a given application, service, or service extension).
- Leveraging the legacy investment”
- Organizational agility
- Using ESB you can decouple business from application any
change in business rules will only impact business rules engine
- “best-of-breed" technology. Because SOA establishes a vendor-
neutral communications framework, it frees IT departments from
being chained to a single proprietary development and/or
middleware platform.”
- “Establishing standardized XML data representation”
“understanding SOA performance requirements”
“SOA's reliance on Web services deepens its dependence on XML
data representation, which, in turn, can magnify XML processing-
related performance challenges. For example, Web services
security measures, such as encryption and digital signing, add new
layers of processing to both the senders and recipients of messages.
Critical to building a successful service-oriented solution is
understanding the performance requirements of your solution and
the performance limitations of your infrastructure ahead of time.
This means:
- Testing the message processing capabilities of your environments
prior to investing in Web services.
- Stress-testing the vendor supplied processors (for XML, XSLT,
SOAP, etc.) you are planning to use.
- Exploring alternative processors, accelerators, or other types of
supporting technology, if necessary. For example, the XML-binary
Optimized Packaging (XOP) and SOAP Message Transmission

10. 10
Optimization Mechanism (MTOM) specifications developed by
the W3C. (For more information, visit www.w3c.org.)
Performance is also one of the reasons coarse-grained service
interfaces and asynchronous messaging are emphasized when
building Web services.
.
The Evolution of SOA
SOA as an architecture modeled around three basic components:
the service requestor, the service provider, and the service registry
First-generation Web services standards fulfilled this model as
follows:
- WSDL described the service.
- SOAP provided the messaging format used by the service and its
requestor.
- UDDI provided the standardized service registry and discovery
format.
Service design
We explore both of these design classifications in the following
two sections:
- service roles (temporary classifications) according to the situation
- service models (permanent classifications)
A Web service is capable of assuming different roles, depending on
the context within which it is used
Roles 5 roles

11. 11
1-Service provider
2-Service requester or consumer
3-Intermediary
Traditional point to point communication is less flexible and not
scalable anther design is Intermediaries
1- passive eg load balancing service
2- active

12. 12
3- initial sender ultimate receiver
Initial senders are simply service requestors that initiate the
transmission of a message. Therefore, the initial sender is always
the first Web service in a message path. The counterpart to this role
is the ultimate receiver. This label identifies service providers that
exist as the last Web service along a message's path
4-Service compositions
Any service can enlist one or more additional services to complete
a given task. Further, any of the enlisted services can call other
services to complete a given sub-task. Therefore, each service that
participates in a composition assumes an individual role of service
composition member
Service models

13. 13
1-Business service model
business service represents the most fundamental building block. It
encapsulates a distinct set of business logic within a well-defined
functional boundary. It is fully autonomous ,as business services
are frequently expected to participate in service compositions.
it represents a corporate entity or information
2-Utility service model
Any generic Web service or service agent designed for potential
reuse can be classified as a utility service. The key to achieving
this classification is that the reusable functionality be completely
generic and non-application specific in nature ex load balancer
service or HijDate service

14. 14
3-Controller service model
acting as the parent service to service composition members
Service compositions are comprised of a set of independent
services that each contribute to the execution of the overall
business task. The assembly and coordination of these services is
often a task in itself and one that can be assigned as the primary
function of a dedicated service or as the secondary function of a
service that is fully capable of executing a business task
independently. The controller service fulfills this role.
Service descriptions (with WSDL)
Service endpoints and service descriptions
A WSDL describes the point of contact for a service provider, also
known as the service endpoint or just endpoint. It provides a
formal definition of the endpoint interface (so that requestors
wishing to communicate with the service provider know exactly
how to structure request messages) and also establishes the
physical location (address) of the service.

15. 15
A WSDL service description can be separated into two parts:
- abstract description
- concrete description
WSDL definitions stored implementation information separately
from the actual interface design. This resulted in an interface
definition that existed independently from the transport protocols
to which it was eventually bound
Abstract description
An abstract description establishes the interface characteristics of
the Web service without any reference to the technology used to
host or enable a Web service to transmit messages. By separating
this information, the integrity of the service description can be
preserved regardless of what changes might occur to the
underlying technology platform.
three main parts that comprise an abstract description
portType, operation, and message
The parent portType section of an abstract description provides a
high-level view of the service interface by sorting the messages a
service can process into groups of functions known as operations.
Each operation represents a specific action performed by the
service. A service operation is comparable to a public method used
by components in traditional distributed applications. Much like
component methods, operations also have input and output
parameters. Because Web services rely exclusively on messaging-
based communication, parameters are represented as messages.
Therefore, an operation consists of a set of input and output
messages

16. 16
The term "portType" is being renamed to "interface" in version 2.0
of the WSDL specification.
Concrete description
Represents the real, implemented technology. Because the
execution of service application logic always involves
communication, the abstract Web service interface needs to be
connected to a physical transport protocol. This connection is
defined in the concrete description portion of the WSDL file,
which consists of three related parts:
binding, port, and service
A WSDL description's binding describes the requirements for a
service to establish physical connections or for connections to be
established with the service. In other words, a binding represents
one possible transport technology the service can use to
communicate. SOAP is the most common form of binding, but
others also are supported. A binding can apply to an entire interface
or just a specific operation.
Related to the binding is the port, which represents the physical
address at which a service can be accessed with a specific protocol.
This piece of physical implementation data exists separately to
allow location information to be maintained independently from
other aspects of the concrete description. Within the WSDL
language, the term service is used to refer to a group of related
endpoints.
Note
The term "port" is being renamed "endpoint" in version 2.0 of the
WSDL specification.

17. 17
Content of HelloService.wsdl file
<definitions name="HelloService"
targetNamespace="http://www.examples.com/wsdl/HelloService.w
sdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
<portType name="Hello_PortType">
<operation name="sayHello">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
<binding name="Hello_Binding" type="tns:Hello_PortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="sayHello">
<soap:operationsoapAction="sayHello"/>
<input>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice"

18. 18
use="encoded"/>
</input>
<output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice"
use="encoded"/>
</output>
</operation>
</binding>
<service name="Hello_Service">
<documentation>WSDL File for
HelloService</documentation>
<port binding="tns:Hello_Binding" name="Hello_Port">
<soap:address
location="http://www.examples.com/SayHello/">
</port>
</service>
</definitions>
Metadata and service contracts

19. 19
WSDL definitions frequently rely on XSD schemas to formalize
the structure of incoming and outgoing messages. Another
common supplemental service description document is a policy.
Policies can provide rules, preferences, and processing details
above and beyond what is expressed through the WSDL and XSD
schema documents.
So now we have up to three separate documents that each describe
an aspect of a service:
- WSDL definition

20. 20
- XSD schema
- policy
Each of these three service description documents can be classified
as service metadata, as each provides information about the
service. Service description documents can be collectively viewed
as establishing a service contracta set of conditions that must be
met and accepted by a potential service requestor to enable
successful communication.
Note that a service contract can refer to additional documents or
agreements not expressed by service descriptions. For example, a
Service Level Agreement (SLA) agreed upon by the respective
owners of a service provider and its requestor can be considered
part of an overall service contract
Semantic description
the most challenging part of providing a complete description of a
Web service is in communicating its semantic qualities.
Most of the time service semantics are assessed by humans, either
verbally by discussing the qualities of a service with its owner, or
by reading supplementary documentation published alongside
service descriptions
Examples of service semantics include:
- how a service behaves under certain conditions
- how a service will respond to a specific condition
- what specific tasks the service is most suited for
UDDI Service description advertisement and discovery

21. 21
Public registries accept registrations from any organizations,
Private registries can be implemented within organization
boundaries to provide a central repository for descriptions of all
services the organization develops, leases, or purchases.
Following are descriptions of the primary parts that comprise
UDDI registry records.
Business entities and business services
Each public registry record consists of a business entity containing
basic profile information about the organization (or service
provider entity). Included in this record are one or more business
service areas, each of which provides a description of the services
offered by the business entity.
Binding templates and tModels

22. 22
Registry records follow the same logic in that they store binding
information in a separate area, called the binding template.
Each business service can reference one or more binding
templates. The information contained in a binding template may or
may not relate to an actual service. For example, a binding
template may simply point to the address of a Web site. However,
if a Web service is being represented, then the binding template
references a tModel. The tModel section of a UDDI record
provides pointers to actual service description
<businessEntitybusinessKey="uuid:C0E6D5A8-C446-4f01-99DA-
70E212685A40"
operator="http://www.ibm.com"
authorizedName="John Doe">
<name>Acme Company</name>
<description>
We create cool Web services
</description>
<contacts>
<contact useType="general info">
<description>General Information</description>
<personName>John Doe</personName>
<phone>(123) 123-1234</phone>
<email>jdoe@acme.com</email>
</contact>
</contacts>
<businessServices>
...
</businessServices>
<identifierBag>
<keyedReference
tModelKey="UUID:8609C81E-EE1F-4D5A-B202-
3EB13AD01823"

23. 23
name="D-U-N-S"
value="123456789" />
</identifierBag>
<categoryBag>
<keyedReference
tModelKey="UUID:C0B9FE13-179F-413D-8A5B-
5004DB8E5BB2"
name="NAICS"
value="111336" />
</categoryBag>
</businessEntity>
<businessServiceserviceKey="uuid:D6F1B765-BDB3-4837-
828D-8284301E5A2A"
businessKey="uuid:C0E6D5A8-C446-4f01-99DA-
70E212685A40">
<name>Hello World Web Service</name>
<description>A friendly Web service</description>
<bindingTemplates>
...
</bindingTemplates>
<categoryBag />
</businessService>
<bindingTemplateserviceKey="uuid:D6F1B765-BDB3-4837-
828D-8284301E5A2A"
bindingKey="uuid:C0E6D5A8-C446-4f01-99DA-
70E212685A40">
<description>Hello World SOAP Binding</description>
<accessPointURLType="http">
http://localhost:8080
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo

24. 24
tModelKey="uuid:EB1B645F-CF2F-491f-811A-
4868705F5904">
<instanceDetails>
<overviewDoc>
<description>
references the description of the
WSDL service definition
</description>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
<tModeltModelKey="uuid:xyz987..."
operator="http://www.ibm.com"
authorizedName="John Doe">
<name>HelloWorldInterface Port Type</name>
<description>
An interface for a friendly Web service
</description>
<overviewDoc>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</tModel>
Messaging (with SOAP)

25. 25
As of version 1.2 of the SOAP specification, the word "SOAP" is
no longer an acronym that stands for "Simple Object Access
Protocol." It is now considered a standalone term.
Envelope, header, and body
Every SOAP message is packaged into a container known as an
envelope. Much like the metaphor this conjures up, the envelope is
responsible for housing all parts of the message
Each message can contain a header, an area dedicated to hosting
meta information. In most service-oriented solutions, this header
section is a vital part of the overall architecture

26. 26
The actual message contents are hosted by the message body,
which typically consists of XML formatted data. The contents of a
message body are often referred to as the message payload
Header blocks
Message independence is implemented through the use of header
blocks, packets of supplementary meta information stored in the
envelope's header area. Header blocks outfit a message with all of
the information required for any services with which the message
comes in contact to process and route the message in accordance
with its accompanying rules, instructions, and properties. What this
means is that through the use of header blocks, SOAP messages
are capable of containing a large variety of supplemental
information related to the delivery and processing of message
contents
The use of header blocks has elevated the Web services framework
to an extensible and composable enterprise-level computing
platform. Practically all WS-* extensions are implemented using
header blocks.
Examples of the types of features a message can be outfitted with
using header blocks include:
- processing instructions that may be executed by service
intermediaries or the ultimate receiver
- routing or workflow information associated with the message
- security measures implemented in the messagereliability rules
related to the delivery of the message
- context and transaction management information
- correlation information (typically an identifier used to associate a
request message with a response message)
Message styles

27. 27
theWSDL binding element that we need to take a closer look at. A
WSDL binding describes how the service is bound to a messaging
protocol, either HTTP GET/POST, MIME, or SOAP. In practice,
SOAP is the most universally used protocol; it is SOAP that the
RPC/document distinction refers to. Usually HTTP(S) is used as
transport protocol for the SOAP message – "SOAP over
HTTP(S)."
The <wsdl:binding> element of the WSDL contains a pair of
parameters that influence the form of the resulting SOAP
messages: binding style (RPC or document) and use (encoded or
literal). See how style and use are defined in the WSDL fragment
below:
The "Style" Attribute
WSDL 1.1 specifies the style of the binding as either RPC or
document. This choice corresponds to how the SOAP payload -
i.e., how the contents of the <soap:Body> element - can be
structured. Here are some details of how each style affects the
contents of <soap:Body>:
- Document: the content of <soap:Body> is specified by XML
Schema defined in the <wsdl:type> section. It does not need to
follow specific SOAP conventions. In short, the SOAP message is
sent as one "document" in the <soap:Body> element without
additional formatting rules having to be considered. Document
style is the default choice.
- RPC: The structure of an RPC style <soap:Body> element needs
to comply with the rules specified in detail in Section 7 of the
SOAP 1.1 specification. According to these rules, <soap:Body>
may contain only one element that is named after the operation,
and all parameters must be represented as sub-elements of this
wrapper element.

28. 28
.
SOAP has its roots in synchronous remote procedure calls over
HTTP and the appearance of the document accordingly followed
these conventions. Later, it was seen as a simplification to use
arbitrary XML in the SOAP body without adhering to conventions.
This preference is reflected in the document style WSDL
documents. So far, both options are represented in the WSDL
specification and the choice of one or the other is mainly a
question of personal taste since most SOAP clients today accept
both versions.
The "Use" Attribute
The use attribute specifies the encoding rules of the SOAP
message. This is also done within the <wsdl:binding> element, as
seen in the example above. The value can be encoded or literal. It
refers to the serialization rules followed by the SOAP client and
the SOAP server to interpret the contents of the <Body> element in
the SOAP payload.
use="literal" means that the type definitions literally follow an
XML schema definition.
use="encoded" refers to the representation of application data in
XML, usually according to the SOAP encoding rules of the SOAP
1.1 specification.
Example base 64 encoding
The combination of the style and use attributes leads to four
possible style/use pairs:
- RPC/encoded
- RPC/literal
- document/encoded
- document/literal

29. 29
Some of these combinations are rarely used in practice, such as
document/encoded. In general, the literal use is gaining
importance, and as far as RPC/encoded is concerned, the Web
Services Interoperability Organization (WS-I) in its Basic Profile
Version 1.0a of August 2003 ruled out the use of SOAP encoding
with web services. Document/literal and RPC/literal will be the
only allowed style/use combinations in the future.
The SOAP specification was originally designed to replace
proprietary RPC protocols by allowing calls between distributed
components to be serialized into XML documents, transported, and
then deserialized into the native component format upon arrival. As
a result, much in the original version of this specification centered
around the structuring of messages to accommodate RPC data.
SOA relies on document-style messages to enable larger payloads,
coarser interface operations, and reduced message transmission
volumes between services
Here is the SOAP request:
POST /Quotation HTTP/1.0
Host: www.xyz.org
Content-Type: text/xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<SOAP-ENV:Bodyxmlns:m="http://www.xyz.org/quotations">
<m:GetQuotation>

30. 30
<m:QuotationsName>MiscroSoft</m:QuotationsName>
</m:GetQuotation>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
A corresponding SOAP response will look like :
HTTP/1.0 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<SOAP-ENV:Bodyxmlns:m="http://www.xyz.org/quotation">
<m:GetQuotationResponse>
<m:Quotation>Here is the quotation</m:Quotation>
</m:GetQuotationResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Header
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="http://www.tutorialspoint.com/transaction/"
SOAP-ENV:mustUnderstand="true">5</t:Transaction>
</SOAP-ENV:Header>
...

31. 31
...
</SOAP-ENV:Envelope>
Messages
Envelope, header, and body
Every SOAP message is packaged into a container known as an
envelope. Much like the metaphor this conjures up, the envelope is
responsible for housing all parts of the message
Service endpoints and service descriptions
Attachments
To facilitate requirements for the delivery of data not so easily
formatted into an XML document, the use of SOAP attachment
technologies exist. Each provides a different encoding mechanism
used to bundle data in its native format with a SOAP message.
SOAP attachments are commonly employed to transport binary
files, such as images
Faults
Finally, SOAP messages offer the ability to add exception handling
logic by providing an optional fault section that can reside within
the body area. The typical use for this section is to store a simple
message used to deliver error condition information when an
exception occurs
Node types
As with the services that use them, the underlying SOAP nodes are
given labels that identify their type, depending on what form of

32. 32
processing they are involved with in a given message processing
scenario.
Below is a list of type labels associated with SOAP nodes (in
accordance with the standard SOAP Processing Model). You'll
notice that these names are very similar to the Web service roles
we discussed at the beginning of this chapter. The SOAP
specification has a different use for the term "role" and instead
refers to these SOAP types or labels as concepts.
1. SOAP sendera SOAP node that transmits a
message
2. SOAP receivera SOAP node that receives a
message
3. SOAP intermediarya SOAP node that receives
and transmits a message, and optionally processes
the message prior to transmission
4. initial SOAP senderthe first SOAP node to transmit
a message
5. ultimate SOAP receiverthe last SOAP node to
receive a message
SOAP intermediaries
The same way service intermediaries transition through service
provider and service requestor roles, SOAP intermediary nodes
move through SOAP receiver and SOAP sender types when
processing a message
SOAP nodes acting as intermediaries can be classified as
forwarding or active. When a SOAP node acts as a forwarding
intermediary, it is responsible for relaying the contents of a
message to a subsequent SOAP node. In doing so, the intermediary
will often process and alter header block information relating to the
forwarding logic it is executing. For example, it will remove a

33. 33
header block it has processed, as well as any header blocks that
cannot be relayed any further.
Active intermediary nodes are distinguished by the type of
processing they perform above and beyond forwarding-related
functions. An active intermediary is not required to limit its
processing logic to the rules and instructions provided in the
header blocks of a message it receives. It can alter existing header
blocks, insert new ones, and execute a variety of supporting
actions.
Message paths
A message path refers to the route taken by a message from
when it is first sent until it arrives at its ultimate destination.
Therefore, a message path consists of at least one initial
sender, one ultimate receiver, and zero or more
intermediaries. Mapping and modeling message paths
becomes an increasingly important exercise in SOAs, as the
amount of intermediary services tends to grow along with
the expansion of a service-oriented solution. Design
considerations relating to the path a message is required to
travel often center around performance, security, context
management, and reliable messaging concerns.
Note also that a message path is sometimes not
predetermined. The use of header blocks processed
by intermediaries can dynamically determine the
path of a message. This may be the result of routing
logic, workflow logic, or environmental condition