2. What is SOAP?
• SOAP stands for Simple Object Access Protocol
• Simply;
▫ XML formatted message in order to exchange
information among applications or services.
• SOAP is a standard that defines the Web
Services protocol. While HTTP is the low-level
protocol, also used by the Internet, SOAP is the
specific format for exchanging Web Services
data over this protocol
3. What is SOAP?
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP communicates via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C recommendation
4. A little bit about its history
• SOAP was originally designed by Dave Winer,
Don Box, Bob Atkinson, and Mohsen Al-Ghosein
in 1998, with backing from Microsoft (where
Atkinson worked at the time), as an object-
access protocol.
• The SOAP specification is currently maintained
by the XML Protocol Working Group of the
World Wide Web Consortium.
• SOAP is now recommonded by W3C
5. Advantages
• Using SOAP over HTTP allows for easier
communication through proxies and firewalls than
previous remote execution technology (but not
required!).
• SOAP is versatile enough to allow for the use of
different transport protocols. The standard stacks
use HTTP as a transport protocol, but other
protocols are also usable (e.g. SMTP, RSS).
• SOAP is platform independent.
• SOAP is language independent.
• SOAP is simple and extensible.
6. Disadvantages
• SOAP can be considerably slower than competing middleware technologies.
• When relying on HTTP as a transport protocol and not using WS-
Addressing or an ESB, the roles of the interacting parties are fixed. Only
one party (the client) can use the services of the other. Developers must use
polling instead of notification in these common cases.
• Most uses of HTTP as a transport protocol are done in ignorance of how the
operation would be modeled in HTTP. This is by design (with analogy to
how different protocols sit on top of each other in the IP stack), but the
analogy is imperfect (because the application protocols used as transport
protocols are not really transport protocols). Because of this, there is no way
to know if the method used is appropriate to the operation. This makes
good analysis of the operation at the application-protocol level problematic
at best with results that are sub-optimal (if the POST-based binding is used
for an application which in HTTP would be more naturally modeled as a
GET operation).
• Although SOAP is an open standard, not all languages offer appropriate
support. Java, .NET and Flex offer excellent SOAP integration and/or IDE
support. Python and PHP support is much weaker.
7. Mutual Relations
• WSDL is to list available services
• SOAP is a protocol in order to exchange
information through defined services by WSDL
(is not always true)
…
<binding name="CustomerSOAPBinding“ interface="tns:CustomerInterface“ type=http://www.w3.org/2006/01/wsdl/soap
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
<operation ref="tns:getCustomerAddress“ wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</binding>
<service name="CustomerService“ interface="tns:CustomerInterface">
<endpoint name="CustomerEndpoint“ binding="tns:CustomerSOAPBinding" address=http://soa-in-practice.com/customer20 />
</service>
…
8. Some Technical Specifications
• Syntax
▫ A SOAP message MUST be encoded using XML
▫ A SOAP message MUST use the SOAP Envelope
namespace
▫ A SOAP message MUST use the SOAP Encoding
namespace
▫ A SOAP message must NOT contain a DTD
reference
▫ A SOAP message must NOT contain XML
Processing Instructions
10. Some Technical Specifications
• The xmlns:soap should always have the value of:
"http://www.w3.org/2001/12/soap-envelope".
• The namespace defines the Envelope as a SOAP Envelope.
• If a different namespace is used, the application generates an
error and discards the message.
• The encodingStyle attribute is used to define the data types used in
the document. This attribute may appear on any SOAP
element, and applies to the element's contents and all child
elements.
• A SOAP message has no default encoding.
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
11. Some Technical Specifications
• The SOAP Header Element
▫ The optional SOAP Header element contains
application-specific information (like
authentication, payment, etc) about the message.
▫ If the Header element is present, it must be the
first child element of the Envelope element.
▫ The mustUnderstand attribute can be used to indicate
whether a header entry is mandatory or optional
for the recipient to process.
▫ The SOAP actor attribute is used to address the
Header element to a specific endpoint.
12. Some Technical Specifications
• The SOAP Header Element cont.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:actor="http://www.w3schools.com/appml/">234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>
13. Some Technical Specifications
• The SOAP Body Element
▫ The required SOAP Body element contains the
actual SOAP message intended for the ultimate
endpoint of the message.
▫ Immediate child elements of the SOAP Body
element may be namespace-qualified.
14. Some Technical Specifications
• The SOAP Body Element cont.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
15. Some Technical Specifications
• The SOAP Body Element cont.
▫ Possible response
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
16. Some Technical Specifications
• The SOAP Body Element cont.
▫ The SOAP Fault Element
▫ The optional SOAP Fault element is used to
indicate error messages.
▫ If a Fault element is present, it must appear as a
child element of the Body element. A Fault
element can only appear once in a SOAP message.
17. Some Technical Specifications
• The SOAP Body Element cont.
▫ The SOAP Fault Element
Sub Element Description
<faultcode> A code for identifying the fault
<faultstring> A human readable explanation of the fault
<faultactor> Information about who caused the fault to happen
<detail> Holds application specific error information related to
the Body element
18. Some Technical Specifications
• HTTP protocol
▫ HTTP communicates over TCP/IP. An HTTP
client connects to an HTTP server using TCP.
After establishing a connection, the client can
send an HTTP request message to the server:
POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250
...
21. Some Technical Specifications
• Manner of speaking…
service is defined as Price getStockPrice(StockName)
We call the service and return the Price as a type
of int
22. Vendors
• Sun, Java, .NET and Flex offer excellent SOAP
integration.
• Python and PHP support for SOAP is poor.
• Java TM API for XML Web Services, JAX-WS
https://jax-ws.dev.java.net/nonav/jax-ws-21-
ea3/docs/index.html
23. Examples, Glassfish, java
• Deploying Web Services in Glassfish
….
@WebService
public class CustomerWS {
…
@WebMethod
public boolean checkCustomer(String email)
{…}
…
}
• Generation of WSDL will be automated.
• The conversation of SOAP will take place without notice.
24. Examples, JAX-WS, java
• wsimport : The tool reads a WSDL and generates
all the required artifacts for web service
development, deployment, and invocation.
▫ After deploying at one point, this tool will read the
WSDL and will generate classes for the client in
order to use the service.
• Usage:
CustomerWSService service = new CustomerWSService();
CustomerWS customerWS = service.getCustomerWSPort();
boolean doesHave = customerWS.checkCustomer(“hguvence@gmail.com”);
27. Alternatives
• REST (Representational state transfer)
▫ An Architectural Style, Not a Standard
• RPC (Remote Procedure Call), middleware
technologies such as CORBA
28. Conclusion
• Even though it is important to know the format of SOAP,
why and when we use it is more important.
• We use it for integrity with the world. It is like using a
single language for benefits! Except cultural values :)
• No need to develop tools to send or to parse SOAP
messages, big vendors already did it. And they work
efficiently. Many people are using. So, you- use it! Don’t
loose time!
• Tools will help you in developing services and connecting
to them in order for you to design your services well. So
you don’t have to worry about SOAP format at all!
29. References, Resources
• http://www.w3.org/TR/soap/
• specs: http://www.w3.org/TR/soap12-part1/
• http://www.w3schools.com/SOAP/soap_intro.asp
• http://searchsoa.techtarget.com/generic/0,295582,
sid26_gci1049566,00.html
• SOA in Practice, The Art of Distributed System
Design, August 2007, p.234-235
• http://www.xfront.com/REST-Web-Services.html
• http://en.wikipedia.org/wiki/SOAP