The slides provide a major overview on SOAP protocol, and demonstrates a working example that uses SOAP for RPC. It uses WCF/visual studio and Apache Axis for the implementation.
1. SOAP: SIMPLE OBJECT ACCESS
PROTOCOL
Mohammad Masudur Rahman
Software Research Lab, Department of Computer Science
University of Saskatchewan
masud.rahman@usask.ca
CMPT 842: Mobile & Cloud Computing
3. WEB SERVICE & SOAP
Web Application (Web App)
Web application is a client-server software application in
which the client runs in a web browser.
Web Service (WS)
A software system to support interoperable machine-to-
machine interaction over a network (W3C)
Web Service Description Language (WSDL)
XML based specification of a web service.
Simple Object Access Protocol (SOAP)
An XML based communication protocol for web service over
HTTP or SMTP.
Interoperability
Having clear interface by a system for communication with
other information systems. 3
4. OUTLINE OF TALK
4
Web Service
Overview Architecture History & Evolution
REST SOAP
Overview History Specification Example
Security
Contrast
Tools
5. WEB SERVICE (WS)
Web service is a component of web application.
A type of Application Programming Interface (API)
that operates over HTTP or SMTP
Targets machine-to-machine communication using
clear service specifications.
Follows XML-based protocols: SOAP/XML-RPC
Follows JSON based protocols: REST, also called
Web API (growing popularity).
Uses WSDL/WADL and UDDI for service
publishing
Basically useful for business communication, and
reuse of legacy systems. 5
6. HISTORY OF WEB SERVICE
1994--97: HTTP, TCP/IP as mainstream
business/communication protocol in the web.
1998: XML 1.0 standardization by W3C
1998: XML-RPC (SOAP) by Dave Winer, Userland Software
& Microsoft.
1999: SOAP 1.0 by Mircosoft, demoed to IBM.
2000: SOAP 1.1 in cooperation with IBM.
May, 2000: SOAP 1.1 submitted to W3C
Fall, 2000: WSDL 1.0 announced (MSFT+IBM)
March, 2001: WSDL submitted to W3C
September, 2000: UDDI 1.0 announced (Microsoft +Arriba)
December, 2000: Oracle, HP, Sun, IBM & Microsoft committed
to web services.
6
Source: http://www.informationweek.com/from-edi-to-xml-and-uddi-a-brief-history-of-web-services/d/d-id/1012008?
Source: http://www.w3.org/2004/Talks/1117-sb-gartnerWS/slide8-0.html
7. EVOLUTION OF WEB SERVICE
(MICROSOFT PERSPECTIVE)
Component Object Model (COM)
Reuse of components from various languages
Windows service, Microsoft Office family, Media Foundation
Distributed Component Object Model (DCOM)
Remote method invocations using COM
Dot Net Remoting
Software as a service, using TcpChannels, Legacy reuse
Web Service
Distributed application using SOAP, HTTP, & XML
Window Communication Foundation (WCF)
Improves WS, targets SOA, adds JSON, REST
7
Source: http://programmingwithwcf.blogspot.ca/2010/06/history-of-wcf.html
8. WEB SERVICE ARCHITECTURE BY W3C
(SOAP-BASED)
8
Discovery
Agency
Service
Provider
Service
Requestor
Service
Service
Description
(WSDL)
Publish
Find
Ref: Service
Description
(WSDL)
Client
Interact
SOAP
UDDI
UDDI = Universal Description, Discovery, and Integration
[ http://uddi.xml.org/ ]
• 3 Parties
• 2 Components
• 3 Actions
10. TOOLS FOR UDDI (PUBLISH/FIND)
UDDI4J: Open source tool for Java
Systinet: UDDI client library
Apache Scout: Apache JAXR based
Apache jUDDI: Wrapper on Scout + extra
UDDI4r: Ruby implementation for UDDI
UDDI Lite
UDDI4Py: For Python by IBM
Ruddi: Open source, Java-based
Eclipse & Visual Studio: Built-in support.
10
Source: http://searchsoa.techtarget.com/answer/Open-source-UDDI-tools
11. OUTLINE OF TALK
11
Web Service
Overview Architecture History & Evolution
REST SOAP
Overview History Specification Example
Security
Contrast
Tools
12. SIMPLE OBJECT ACCESS PROTOCOL (SOAP)
An XML-based protocol for accessing web service.
A messaging protocol among web applications.
Defines a set of rules for structuring messages
passed among application over internet.
Not tied to any OS or programming language.
Not tied to any protocol, but mostly used with HTTP
& SMTP for their popularity
Analogous to RPC in DCOM, CORBA, RMI
Created by Dave Winer, Userland Software &
Microsoft.
W3C recommendation since June 24, 2003 12
13. AN EXAMPLE USE-CASE (SOAP)
Simple web service to offer employee information within
an organization, can be diverse like AWS.
Service module accesses Employee database.
Client ↔ Listener communicates using SOAP.
Client encodes request as a SOAP request.
Listener decodes the request, and collect results from
the service methods.
Listener encodes the result as a SOAP response. 13
Employee
database
http://www.soapuser.com/basics1.html
14. EVOLUTION HISTORY (SOAP)
1998: Development of SOAP started, no standard
schema for XML. Supported limited data types.
1999: SOAP 1.0 announced by Dave Winer & Microsoft.
Not submitted to W3C, but IBM.
2000: SOAP 1.1 announced by MSFT & IBM, still a
widely used version.
Based on XML 1.0
Fault Codes.
Mass vendor supports, E-Speak (1999) by HP didn’t get that.
2007: SOAP 1.2 by XML Protocol Working Group
Based on XML Infoset >> XML 1.0
Better interoperability
Truly protocol independent
Formalized extensibility
Better support of web standards, internationalization. 14
http://www.w3.org/2003/06/soap11-soap12.html
15. WSDL FILE (FOUR ELEMENTS)
15
Types: XML data types for all input and
output messages in the service
Message: Defines the input & output
parameters for each operation
PortType: Operations (functions) offered
by the web service
Binding: Defines protocol and data
format for each port type
19. EXAMPLE SOAP REQUEST
19
RPC parameters
• GetFactorial (method name)
• number = 8 (method parameter)
Optional header
Fig: SOAP Request example
20. EXAMPLE SOAP RESPONSE
20
Fig: SOAP Response example
RPC response
• GetFactorial Response
• GetFactorialResult , 8!=40320
21. HTTP + SOAP REQUEST
21
HTTP Post +
Headers
SOAP request
Fig: SOAP on top of HTTP
22. WEB SERVICE SECURITY (WS-SECURITY)
An extension of SOAP by OASIS to apply security to
web services.
SOAP depends of HTTP, TCP/IP, that provides transport
layer security.
WS-Security provides application layer security
Focus: message integrity, confidentiality, and
sender’s identity.
Based on XML Signature & XML Encryption
Adds security features in SOAP message header.
Applies X.509, Kerberos, SAML, UserID/password.
22
https://en.wikipedia.org/wiki/WS-Security
23. SECURED SOAP MESSAGE
23
Fig: Secured SOAP request
User credentials for
authentication & authorization
Payload increases when
Signature & Encryption
added.
Hampers overall
performance significantly
24. MESSAGE TRANSMISSION OPTIMIZATION
MECHANISM (MTOM)
Provides optimization
support for sending
attachments: Images,
PDF, Docs.
Applies to XML
Base64Binary data
SOAP envelopes only
contain reference to
attachment, less
message.
XOP = XML-binary
Optimized Packaging
24
25. WEB SERVICE SPECIFICATIONS
Messaging Specification
SOAP
SOAP-over-UDP : SOAP using UDP
SOAP MTOM: Message optimization
WS-Addressing: Message routing
Meta Data Exchange Specifications
WS-Policy: Security/policy advertisement
WSDL, UDDI: Service discovery
WS-Resource Framework: Stateful capabilities
Security Specifications
WS-Signature: Message integrity
WS-Encryption: Message confidentiality
XML Key Management (XKMS): For security purposes.
WS-Trust : Renewing/validating security tokens 25
Source: https://en.wikipedia.org/wiki/List_of_web_service_specifications
26. SOAP VS. REST
Aspect SOAP REST
Stands for Simple Object Access Protocol Representational State Transfer
What? It’s a protocol It’s an architectural style
Use -- SOAP cannot use REST REST might use SOAP
Coupling + Clear interfaces, tightly coupled
with server
Less coupled, client works like a
browser
Platform + Platform independent Requires HTTP
Bandwidth -- Cost more, slower Cost less, faster
Media type -- XML only, verbosity issue JSON, plain text, XML
Security + SSL + WS-Security Only SSL
Maturity + Matured Less matured
Message size -- Bigger Light weight, mobile computing
Error-handling + Built-in User’s responsibility
Sources: http://www.javatpoint.com/soap-vs-rest-web-services, http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/
27
29. EXAMPLE DEMONSTRATION
(WCF SERVICE)
Name: MathUtilService
Implements IMathUtilService interface/contract
WCF-based web service using Visual Studio 2012
Uses SOAP, WSDL
3 Functions:
GetFactorial(n): returns factorial of a number
IsPrime(n): determines if a number is prime or not.
GetCombination(n, r): returns nCr
Implemented in C#, runs in localhost.
Generates a WSDL:
http://localhost:50785/MathUtilService.svc?singleWsdl
29
30. EXAMPLE DEMONSTRATION (C# CLIENT)
Name: MathUtilClient-CS
Service WSDL can be to the project as a reference.
VS creates stub classes from WSDL specifications
automatically.
Service end-points are automatically added to
app.config file.
Now, it looks like a local object call
Doesn’t need to think of SOAP/WSDL/REST
anything
30
31. EXAMPLE DEMONSTRATION (JAVA, AXIS2)
Name: MathUtilClient-Java
Done on Eclipse IDE Kepler 4.0
Needs Eclipse Java Web Developer Tools
Axis
Xml_rpc
Saaj
Javax_wsdl
Commons-discovery
Apache-commons-logging
Creates stub classes from WSDL similarly
No need to worry about SOAP, WSDL 31
32. EXAMPLE DEMONSTRATION
(JAVA, RAW SOAP)
Name: MathUtilClientRaw
Used javax.xml.soap library
Sent SOAPMessage as request
Received SOAPMessage as response.
Implemented for GetFactorial(n).
Demonstrates platform-independence &
interoperability.
32
Introduce yourself
Today, I am going to talk about SOAP
We know two types of SOAP so far. However, in this talk I would focus on a different type of SOAP
This is a communication protocol.
So SOAP stands for Simple Object Access Protocol
It’s a protocol for web service.
Now before, we jump into the talk, you will probably hear these terms frequently–
Web application which means a client-server application where the client runs in a web browser.
Web Service: A software system which is designed to support machine-to-machine communication over the network. Web service can be a part of a large web application.
WSDL: Web Service Description Language. It is the XML-based specification for the web service. That means the functions/parameters the service provides.
Then comes SOAP: Simple Object Access Protocol, it’s the protocol for web service. That means this protocol is followed during web service consumption.
Interoperability: It’s a property of a system that ensures that the system has clear interfaces for communication with other systems.
This is the outline of my talk:
Quite a big talk, so, please get ready
Our talk will have a hierarchical structure.
First, we focus on web service as logical fist step. We will touch its overview and evolution history, and then we will explore the architecture.
Right now, there exist two dominant architecture– SOAP based and REST based.
We will basically explore the SOAP, REST will be done by another speaker.
In the SOAP, we will focus on its history, evolution, specification, security and finally a working example (like a tutorial)
We will also contrast between REST and SOAP.
Web service is a component of web application
It can be also considered as an API over the internet using HTTP/SMTP
But, it targets machine-2-machine communication.
There are two flavors of web service—XML based SOAP, and JSON/XML based REST
REST based services are also called Web API nowadays.
Services are listed by UDDI directory using WSDL or WADL descriptions.
Now lets look at the history of the web service
By 1997: HTTP, TCP/IP were widely accepted by the major companies all over the world as standard communication protocol.
Now they need a message passing protocol which came at 1998. XML 1.0 was standardized by W3 Consortium.
By this time Dave Winer and colleagues developed XML-RPC, remote procedure call is a hot topic then.
However, XML-RPC is standardized as SOAP.
SOAP 1.0 came at 1999, although developed at 1998. Due to internal politics of Microsoft, it was postponed.
Anyway, MSFT quickly demoed to IBM, IBM liked it and started cooperating.
Soon SOAP 1.1 came out, and later accepted by W3C.
MSFT also worked with IBM, and announced WSDL at 2000
Later, they worked with Arriba, and announced UDDI 1.0 (Universal Description, Discovery and Integration)
More interestingly, five giants came to a contract to promote web services.
Not sure, if that still exist or not.
This is evolution from MSFT’s perspective.
First, Microsoft used COM for talking among different applications from different languages.
Then comes DCOM, that enables RMI with DCOM.
Then comes DotNet Remoting which proves SAAS using TcpChannels. Very useful for legacy business machines.
Then comes Web service, it is more generic, and provides method call service using existing protocols such HTTP, TCP/IP and SOAP.
Then comes WCF, it improves web service to next level. It targets Service Oriented Architecture (SOA), and also provides JSON support+ others.
Now we will see the sequence of their operations:
Once the service provider is done with service development, it can contact the Discovery agency for service listing and publishing.
The provider basically sends the WSDL file that describes the specification of the service.
The UDDI directory keeps the WSDL file, and the service requestor requests for a service.
The discovery agency then sends the WSDL file.
The requestor then develops a client that can consume the service.
In this stage, the client directly communicates with service provider for the service, and here comes the SOAP.
The client follows SOAP for communication with the provider.
Now we will see the sequence of their operations:
Once the service provider is done with service development, it can contact the Discovery agency for service listing and publishing.
The provider basically sends the WSDL file that describes the specification of the service.
The UDDI directory keeps the WSDL file, and the service requestor requests for a service.
The discovery agency then sends the WSDL file.
The requestor then develops a client that can consume the service.
In this stage, the client directly communicates with service provider for the service, and here comes the SOAP.
The client follows SOAP for communication with the provider.
These are the tools available for publishing and finding services from the UDDI, the public service registry for web services.
Also, big generations have their private UDDI directories for publishing and consuming services.
Different languages created tools for UDDI.
So far, we were discussing web service in general.
Now, lets get into SOAP, the messaging protocol for web service.
SOAP stands for Simple Object Access Protocol– as we said.
Although its basically XML based RPC, but probably borrow idea from COM or DCOM, the earlier technologies from Microsoft.
So, its an XML based messaging protocol for the web applications. Mostly targeted for machine-to-machine communication.
It defines a set of rules for message passing.
Not tied to any OS, programming language or protocol. By due wide adoption of HTTP/SMTP, it is implemented over those protocols.
SOAP got W3C recommendation on 2003
It was created by Dave Winer from Userland Soft. & Microsoft.
Now lets see a quick example for the use-case of SOAP.
Suppose, a large organization wants to provide a service that offers employee’s contact information within the organization, and a large database contains such info.
Now, service module is developed with a listener attached to it.
Now if a client application wants to get that service, it has to communicate using SOAP.
The client will encapsulate the request contact for an employee as a SOAP request.
The listener will decode that request, and forwards the request to the service provider.
The service provider accesses the database, and returns the contact info.
Then the result will be encoded as a SOAP response, and sent back to the client.
So, SOAP is basically a messaging protocol like other protocols.
Now, we check the evolution history, and then we go to the detailed architecture.
As discussed earlier SOAP came out at 1999 although its development started on 1998.
But it was not published XML was not standardized. In 1998, XML 1.0 came out from W3C consortium.
Then SOAP 1.0 appeared, but it was quite preliminary at that stage.
However, IBM liked the idea from Microsoft, and worked together to bring out SOAP 1.1.
Then eventually came other technologies like WSDL, UDDI.
Still SOAP 1.1 is still popular and widely used probably.
Then in 2007, XML Protocol working group provided SOAP 1.2.
It’s a major improvement over SOAP 1.1. For example, it provides better support for interoperability, extensibility.
It makes SOAP as protocol independent, and provides better support for web standard such as internationalization.
Now SOAP message is developed based on the information on the available WSDL file.
It contains also four sections: Types, message, portType, and binding.
Types section describes the XML data types for all input/output parameters used in the web service.
Message section defines each of the input/output message items to be communicated with.
PortType enlists the available functions offered by the service.
Binding defines the protocol and data format for each operation offered.
An WSDL file looks like this. Looks quite scary, right?
Very unreadable. Originally, web service is targeted for machine-to-machine communication.
So, machine can read this file pretty well, which we will se later.
Anyway, if we get the Tree View of the file, we can easily identify the elements.
For example, we can see the types that defines the data types for the messages.
Then the message section that defines the messages.
Then here is the portType that shows the operation allowed.
Then the binding section that binds the operations with protocol– HTTP/SMTP
Then the service name, service end points.
This is the skeleton of a SOAP message in general. For both SOAP request or response, it will have these four elements.
The whole message is encapsulated in an Envelope element.
The envelop must contain the encoding information, and it has to be SOAP-encoding.
The comes the optional header, it will contain SOAP message-specific information such as authentication, payment etc. It must be the first element in the message.
Then comes the body. It will contain web service function name and Fault section.
The Fault section contains info about the fault occurred.
This is an Example SOAP request.
This is the optional header.
Here we can see the method name + parameters which we are calling from the client.
For example, we are asking for the factorial of 8.
This is the SOAP response from the server.
Here we see the message name GetFactorialResult.
It contains our result, factorial of 8.
Now, we know SOAP sits on top of HTTP.
So, when SOAP call made using HTTP post, the whole request looks like this.
This is the HTTP method and headers.
And, then this is the SOAP request.
This whole message is sent over the protocol. This is useful, because SOAP can use the popular protocol.
And 100% of the machines support HTTP nowadays, even the firewalls.
So, SOAP is truly platform-independent.
Now, lets focus on the security. Secure operation can be done using SOAP.
HTTP provides transport layer security using SSL, but web service security ensures application layer security.
Basically it has three focuses– message integrity, confidentiality and user identity.
Message integrity checks if the sent message is not tampered– using XML signature.
Message confidentiality encrypts the message—using XML encryption.
User identity checked using hashed credentials.
For example, here we can see the user credentials are added into the SOAP header.
So that the identity of the user can checked in the application layer. For example, in the banking transaction.
However, this additioanl security payload increases message size, and reduces the performance.
So, people worked to optimize the message size.
One such mechanism is message transmission optimization mechanism MTOM.
Especially targeted for sending attachments using web service.
By default, an Image will be converted to XML data type base64Binary string, a long string.
This optimization do not send the attachment directly rather sends the reference to the image.
Thus, message size reduced.
There are also significant improvements on web services as a whole.
For example, WS-addressing is found to enable SOAP message routing.
In the case of data exchange, WS-Policy and resource frameworks are introduced.
In the case of security, key management + trust mechanisms are introduced.
Now, comes the important part. Which one to choose? SOAP or REST.
First of all, SOAP is a protocol and REST is a architectural style.
However, we always get some metrics to compare. For example….
Now, these are the tools available for SOAP-based web service implementation.
Several from Apache, some from Mircosoft, and some from PHP community.
Many of them support both SOAP and REST.
Many use both XML and JSON, to make them useful.
However, we used to of these Apache Axis, and Microsoft WCF.