1.
Define SOAP, describe who maintains the specification, and what purpose it serves in the software
industry.
ANSWER:
SOAP is a lightweight protocol for exchanging XML-based messages between peers in a decentralized,
distributed environment (like the Internet). SOAP messages provide structure and typing for business data
as well as a system for processing that data such that it can be exchanged with disparate systems in a
manner that is independent of any programming language, operating system, hardware, or transport
protocol. Fundamentally, SOAP is a stateless, one-way message exchange framework.
The World Wide Web Consortium (W3C) maintains the SOAP specification.
SOAP is used to achieve application-to-application (A2A) communication among distributed, disparate
systems, specifically business-to-business (B2B) and enterprise application integration (EAI).
2.
Why does SOAP succeed with interoperability while other attempts have failed?
ANSWER:
Other attempts for a communication standard have either been bound to a specific underlying transport
protocol or programming language or platform, represented the data exchanged between systems in binary
form, or haven’t gained widespread support, all of which limit interoperability. The SOAP specification is
independent of the underlying transport protocol used to transmit the data, the programming language(s)
used to build the application, or any other specifics of the underlying platform including the operating
system and hardware. SOAP uses XML to structure the data that is exchanged between systems, so the data
is in text form and is independent of the underlying platform. SOAP has gained widespread acceptance
across the industry including all the major players like Microsoft, IBM, and Sun. The industry has
combined efforts into organizations like W3C, OASIS, and WS-I to ensure that SOAP is successful in
interoperability.
3.
What are XML namespaces used for in a SOAP message?
ANSWER:
The use of XML namespaces eliminates ambiguity among all of the XML elements and attributes in a
SOAP message. Each of the different XML elements in the Header and Body must be identified by a
unique namespace. Since a SOAP message may include several different application-specific XML
elements in the Header and Body, as well as the standard SOAP message elements (Envelope,
Header, Body, and Fault) and their associated attributes, a particular instance of a SOAP message may
contain references to many different namespaces in order to avoid name collisions.
In addition to eliminating ambiguity, XML namespaces in a SOAP message provide versioning and
processing control. For example, a particular namespace can be used to identify a specific version of a
software module that must be used to process the XML data in a namespace-qualified header block. Each
header block in a Header element should be qualified with its own namespace so that SOAP applications
can identify each individual header block and process them appropriately. The XML namespace of a header
block is typically used to not only identify the schema for that header block, but also the processing
requirements.
4.
Describe the SOAP message path and each of its components. Be sure to use SOAP terminology.
ANSWER:
The specification defines SOAP as a decentralized, stateless, one-way message exchange paradigm where
XML messages are passed from an initiator, through zero or more intermediate locations, to a final
destination. The peers exchanging the SOAP message are called SOAP nodes. SOAP nodes handle routing
and processing of the SOAP message and are categorized into one of the following concepts.

SOAP sender: SOAP node that generates and transmits a SOAP message.

SOAP receiver: SOAP node that receives and processes the SOAP message that was generated by a
SOAP sender.

SOAP intermediary: SOAP node that is considered a SOAP receiver as well as a SOAP sender.
Zero or more intermediaries can lie between the initial SOAP sender and the ultimate SOAP
receiver. These intermediaries can perform preprocessing of the message before it reaches its final
destination. Common uses for intermediaries are security, logging, and transactions.
The set of SOAP nodes through which the SOAP message passes, including the initial sender and the
ultimate receiver, are called the SOAP message path. The initial SOAP sender is the SOAP sender that
generated the original SOAP message. In other words, the initial SOAP sender is the SOAP node at the
beginning of the SOAP message path. A SOAP intermediary cannot be the initial SOAP sender since
intermediaries are not at the beginning of the SOAP message path. The ultimate SOAP receiver is a SOAP
receiver that is the final destination of a SOAP message. Simply put, the ultimate SOAP receiver is the
SOAP node at the end of the SOAP message path, and therefore, also cannot be a SOAP intermediary.
1st Intermediary
Initial Sender
Sender
(Client)
Node
5.
SOAP
Message
Intermediary
Node
Ultimate Receiver
(Web Service)
nth Intermediary
SOAP
Message
Intermediary
Node
SOAP
Message
Receiver
(Server)
Node
List and describe each of the four major elements that are used to compose a SOAP message. Which
SOAP element is analogous to what Java class and why?
ANSWER:
The XML document that defines a SOAP message is composed of the following four elements.

Envelope (mandatory): Every XML document must have a root element. The SOAP Envelope
element is the root element of the XML document that defines a SOAP message, and as such, there
can only be one Envelope element. All other SOAP message elements are contained within the
Envelope. The Envelope element serves to package the SOAP message for transport.

Header (optional): The SOAP Header element is optional in a SOAP message, but if it is used,
there can only be one and it must appear as the first child element of the Envelope. The Header
element is an extension mechanism that can be used to pass application-specific information not
contained in the message itself. This information can be processed by zero or more intermediaries,
which can provide value-added services. Typical uses of the Header element include transaction
processing, authentication, and logging.
6.

Body (mandatory): The actual application data that is being transported between applications is
contained in the SOAP Body element, encoded in XML. The Envelope element must contain a
Body element. If no Header element is being used, then the Body element must be the first child
element of the Envelope; otherwise the Body element must immediately follow the Header
element.

Fault (optional): The SOAP Fault element is used to report errors back to a SOAP sender. A
SOAP Fault is analogous to an Exception in Java and is typically mapped to a subclass of
java.lang.Exception. If a Fault is used, it must be present inside of the Body element, and
it must be the only child element of the SOAP Body.
What underlying transport protocol is SOAP typically bound to and why?
ANSWER:
The most common underlying protocol with which SOAP is used is HTTP because HTTP is one of the
most widespread network protocols in use today due to the advent of the Internet and the fact that Web
browsers and Web servers use HTTP to exchange HTML Web pages.
7.
Describe the SOAP extensibility mechanism and how it can be used to interject application-specific
processing into the SOAP message path.
ANSWER:
The Header element provides a standardized framework for implementing arbitrary, user defined
extensibility to a SOAP message. Using header blocks to add functionality to SOAP messages is referred to
as vertical extensibility. The header blocks build on top of the message, thereby vertically extending the
message (both physically and conceptually). One advantage of header blocks is that the act of adding
header blocks to a SOAP message does not alter the original application-specific XML contained in the
Body. Adding extra data to Body would require the initial sender and ultimate receiver to change in order
to know how process the data. Using the header blocks means that the initial sender and ultimate receiver
processing logic doesn’t have to change, but the additional feature can simply be “tacked on” or upgraded
or even removed when necessary.
SOAP intermediaries provide another mechanism for extending SOAP that is referred to as horizontal
extensibility. Whereas vertical extensibility extends the SOAP message (both conceptually and physically)
in a vertical fashion by adding additional information (via header blocks) to the Header element, the idea
behind horizontal extensibility is targeting different parts of the SOAP message for different recipients
(intermediaries). You can add more intermediaries to the message path and extend the message path
“horizontally”. SOAP intermediaries provide a very simple mechanism for distributed systems to scale
(meaning to expand) by adding valuable services along the message path. Valuable services may include
systems that address qualities of service (QoS) like security, transactions, routing, and message persistence.
8.
List and describe the two SOAP message styles and the two popular SOAP encoding styles. Which
message format is the easiest to use? Which message format provides the least amount of coupling?
ANSWER:
The two message styles are as follows.

RPC –An RPC (Remote Procedure Call) style message is designed to model the semantics of
procedure calls made in programming languages like Java where method calls are used to exchange
parameters and return values (synchronous style of communication, usually). Programmers are
familiar with this semantic so the creators of SOAP defined an optional structure for defining an
RPC style request and response SOAP message. In the SOAP defined RPC model, the RPC style
request message contains a single application-specific child element in the Body, which specifies
the method name and a list of input parameters (called in parameters) for the procedure call. The
RPC response message also contains a single child element in the Body, which can be either a
Fault (exceptional condition) or an application-specific element containing the response and any
other parameters (called out parameters). Because SOAP is independent of programming language
and some languages support multiple return parameters from a procedure call, SOAP RPC provides
a structure for handling multiple out parameters.

Document – This message style means that no SOAP formatting rules (like SOAP RPC) are being
applied to the data in the Body. The SOAP Body simply contains one or more XML elements that
hold some arbitrary data the sender and receiver have agreed upon.
The two encoding styles are as follows.

SOAP Encoding – This is an optional set of serialization rules that is defined by the SOAP
specification. Typically SOAP Encoding is used with the RPC message style.

Literal – Literal encoding simply means that the payload of a SOAP message is defined completely
by a schema. The language typically used to express the schema is XML Schema, but not always.
The XML Schema does not always provide the capability that is needed, so other schema languages
are sometimes used in place of, or in concert with, XML Schema. Examples include RELAX NG
and Schematron.
The RPC/Encoded message format is the easiest for the developer, because when using this format, the
SOAP processor does most of the work.
The Document/Literal message format is quickly becoming the most popular format among the SOAP
community. Although it requires the most effort from the developer, it provides the least amount of
coupling and therefore the greatest amount of scalability.
9.
Describe the different methods for indicating the data types in a SOAP message. Which method do
SOAP experts prefer?
ANSWER:
Part 2, section 3 of the SOAP 1.2 specification (section 5 in SOAP 1.1) defines a style of encoding that may
be used which provides support for RPC (Remote Procedure Call) style messaging. This encoding style is
commonly referred to as SOAP Encoding or SOAP Section 5 Encoding. SOAP experts suggest that data in
SOAP messages be structured and typed using XML Schema Part 1: Structures and XML Schema Part 2:
Datatypes because XML Schema is perceived as having a better type system and better interoperability
than SOAP Encoding. SOAP Encoding was developed largely because, when the SOAP 1.1 specification
was written, the XML Schema specification was still in draft form and only supported simple types (like
integers and strings) and not complex types (like your own Java class). Additionally, the XML Schema
structures data in a tree form, which is not nearly as flexible as the object graph form that SOAP Encoding
uses. Often, there isn’t an easy way to map a class in Java to an XML Schema structure such that RPC
messaging is readily supported. Therefore the designers of SOAP created the SOAP Data Model and SOAP
Encoding.
The purpose of the SOAP Data Model is to provide a language independent abstraction for data types used
by common programming languages. The SOAP Data Model represents data as a graph of nodes connected
by directional edges. The purpose of SOAP Encoding is to describe a standard convention for taking a
SOAP Data Model and writing it out as XML. The resultant XML may be used in a SOAP header block or
the SOAP Body. XML by itself provides a very flexible means for encoding data. SOAP Encoding defines
a narrower set of rules than that provided by XML such that SOAP applications will know how to process
data using the SOAP Data Model.
10. Create an XML schema and use that schema in a SOAP message to define the application-specific data
in the SOAP Body.
ANSWER:
XML schema
<?xml version=”1.0” encoding=”UTF-8”?>
<schema xmlns=”http://www.w3.org/2001/XMLSchema”
xmlns:myNs=”http://myNs” targetNamespace=”http://myNs”>
<element name=”Address” type=”myNs:addressType”/>
<complexType name=”addressType”>
<sequence>
<element name=”streetNumber” type=”int”/>
<element name=”city”
type=”string”/>
<element name=”state”
type=”string”/>
</sequence>
</complexType>
<element name=”Person” type=”myNs:personType”/>
<complexType name=”personType”>
<sequence>
<element name=”name” type=”string”/>
<element name=”gender” type=”string”/>
<element name=”address” type=”myNs:addressType”/>
</sequence>
</complexType>
</schema>
SOAP message using XML schema
<?xml version=”1.0” encoding=”UTF-8”?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:myNs=”http://myNs”>
<soap:Body>
<myNs:Person
soap:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”>
<myNs:name>Bill</myNs:name>
<myNs:gender>male</myNs:gender>
<myNs:address id=”1”>
<myNs:streetNumber>1000</myNs:streetNumber>
<myNs:city>Hopkins</myNs:city>
<myNs:state>SC</myNs:state>
</myNs:address>
</myNs:Person>
<myNs:Person
soap:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”>
<myNs:name>Eva</myNs:name>
<myNs:gender>female</myNs:gender>
<myNs:address ref=”1”/>
</myNs:Person>
</soap:Body>
</soap:Envelope>