SOAP is a protocol specification for exchanging structured information between applications, typically in a decentralized, distributed environment. It uses XML as its message format and relies on other protocols like HTTP for message negotiation and transmission. SOAP has a basic structure that includes an envelope, header, body, and optional fault element. It allows for lightweight communication between applications across different operating systems and programming languages. While it provides advantages like portability and interoperability through open standards, SOAP can be slower than other middleware technologies due to its verbose XML format.

1. Introduction to soap
Report
Name
SAFWAN HASHMI
UMAR JAVED MALIK
FAISAL JALIL
Enrollment No
01-134102-067, 01-134102-067,01-233091-009
BS(CS)
Submitted to
MR FAISAL IMRAN
Introduction to soap
HASHMI SAF
12/23/13
Distributed
computing

2. Table of Contants
1. SOAP _________________________________________________________ 3
2. Where did it come from____________________________________________ 3
3. SOAP Specification ______________________________________________ 3
4. Basic Structure of SOAP ___________________________________________4
5. SOAP Parts _____________________________________________________4
6. SOAP with HTTP _________________________________________________5
7. SOAP with ISP ___________________________________________________5
8. Why Not Roll XML Own Protocol ____________________________________6
9. Syntex Rules ____________________________________________________6
10. SOAP Fault Element_______________________________________________6
11. CORBA Vs SOAP ________________________________________________7
12. Advatage of SOAP________________________________________________7
13. Disadvatages of SOAP ____________________________________________7
14. Refrence _______________________________________________________9

3. Introduction to SOAP
SOAP:
SOAP is a protocol specification for exchanging structured information in the
implementation of Web Services in computer networks. It relies on Extensible Markup
Language (XML) for its message format, and usually relies on other Application Layer
protocols, most notably Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer
Protocol (SMTP), for message negotiation and transmission. The following is the structure
of SOAP Envelope,
It is important for application development to allow Internet
communication
between
programs.
Today's
applications
communicate using Remote Procedure Calls (RPC) between
objects like DCOM and CORBA, but HTTP was not designed for
this. RPC represents a compatibility and security problem;
firewalls and proxy servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP,
because HTTP is supported by all Internet browsers and servers. SOAP was created to
accomplish this. SOAP provides a way to communicate between applications running on
different operating systems, with different technologies and programming languages.
Where did it come from?
SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob
Atkinson, and Mohsen Al-Ghosein for Microsoft where Atkinson and Al-Ghosein were
working at the time.[1] The SOAP specification is currently maintained by the XML Protocol
Working Group of the World Wide Web Consortium.
SOAP Specification

Lightweight communication protocol
•
For communication between application
•
Designed to communicate via HTTP
•
Not tied to any component technology and any programming language
•
Based on XML

4. Basic Structure of SOAP
Element
Description
Required
Envelope Identifies the XML document as a SOAP message.
Yes
Header
Contains header information.
No
Body
Contains call and response information.
Yes
Fault
Provides information about errors that occurred while processing the message.
No
SOAP Building Block [2]
SOAP Contains Four Parts
•
An extensible envelope expressing (mandatory)
•
•
who should deal with them,
•
•
what features and services are represented in a message;
Whether they are optional or mandatory.
A set of encoding rules for data (optional)
•
•
•
Exchange instances of application-defined data types and directed graphs
Uniform model for serializing abstract data models that cannot directly be
expressed in XML schema
A Convention for representation RPC (optional)
•
•
How to make calls and responses
A protocol binding to HTTP and HTTP-EF (optional)

5. SOAP Example in HTTP
SOAP Example in SIP

6. Why Not Roll My Own XML Protocol?
•
SOAP allows you to define your particular feature or service in such a way that it
can co-exist with other features and services within a SOAP message
•
What is a feature or a service?
•
•
Payment service
•
Security service
•
Transaction management service
•
•
Authentication service
Privacy service
Not owning the message means easier deployment and better interoperability
Syntax Rules
•
MUST be encoded using XML
•
MUST have a SOAP Envelope
•
CAN have a SOAP header
•
MUST have a SOAP Body
•
MUST use the SOAP Envelope namespace
•
MUST use the SOAP Encoding namespace
•
Must NOT contain a DTD reference
•
Must NOT contain XML Processing
SOAP Fault Element
•
•
•
•
Error messages from a SOAP application are carried inside a Fault element.
Must appear as an element w/in the <Body> element and can only appear once in a
SOAP message.
Fault sub elements:
<faultcode> MUST: --code identifying the error, for use by the software
<faultstring> MUST: --error as a string
<faultactor> MUST(Apps not acting as ultimate destination of SOAP message)
--who caused the error
<detail>
MUST(if contents of Body could not be successfully processed)
--specific error information
Fault Codes:
VersionMismatch
Invalid namespace for the SOAP Envelope Element
MustUnderstand
A child element of the Header element, with the mustUnderstand
attribute
set to “1”, was not understood
Client
The message was incorrectly formed or contained incorrect information.
Server There was a problem with the server so the message could not be process

7. CORBA Vs SOAP
Common Object Request Broker Architecture
CORBA provides a
Component architecture.
Simple Object Access Protocol
true
object-oriented Web services like (UDDI/WSDL/SOAP)
are not providing true object-oriented
component architecture.
Fast Compared to SOAP
Because of the verbose XML format,
SOAP can be considerably slower than
CORBA
Can be difficult to use if server and/or client is HTTP works well with network firewalls
behind a firewall or if network address translation
is being used.
Problems with implementations
It is XML based implementation compare
to CORBA,SOAP Implementation is
easy.
It uses IIOP (Internet Inter ORB Protocol)
Simple XML-based protocol to let
applications exchange information
overHTTP
Advantages of SOAP
•
Portability
•
Firewall friendliness
•
Use of open standards
•
Interoperability
•
Universal acceptance.
Language neutrality:
SOAP can be developed using any language.
•
Interoperability and Platform Independence.
SOAP can be implemented in any language and can be executed in any
platform.
SOAP messages are in very simple XML format.
•
Scalability:
SOAP uses HTTP protocol for transport due to which it becomes scalable.
Disadvantages of SOAP

When using standard implementations and the default SOAP/HTTP binding, the XML
infoset is serialized as XML. Because of the verbose XML format, SOAP can be

8. •
considerably slower than competing middleware technologies such as CORBA or ICE
This may not be an issue when only small messages are sent.[3] To improve
performance for the special case of XML with embedded binary objects, the Message
Transmission Optimization Mechanism was introduced.
Too much reliance on HTTP
•
Statelessness
•
Serialization by value and not by reference

9. References
1 "Exclusive .NET Developer's Journal "Indigo" Interview with Microsoft's Don Box".
Dotnet.sys-con.com. Retrieved 2012-10-04.
2 SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". W3C. April 27, 2007.
Retrieved 2012-06-15. "Note: In previous versions of this specification the SOAP name was
an acronym. This is no longer the case. (Underneath section 1. Introduction)"
3 Olson, Mike; Ogbuji, Uche (July 3, 2002). "The Python Web services developer: Messaging
technologies compared" IBM developerWorks. Retrieved 2011-02-01.