SOAP Architecture - Njit

squabbletownmushySoftware and s/w Development

Dec 14, 2013 (3 years and 7 months ago)


Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Simplified Object Access Protocol

Inder Nandrajog

CIS 679 Management of IS

Spring, 2001


Over the last few years information systems have been revolutionized
by the explosive popularity of the Internet. The Web has completely
the way we conduct business today. The strategic
relevance of information systems has never before been felt to the
extent that it is today.

While the importance of the Internet for today’s business cannot be
disputed, how the leaders of today can capit
alize on it and use it to
attain a sustainable competitive advantage is still quite a mystery.
One area that has proven to be very effective in attaining such an
advantage has been
collaborative systems
, where multiple companies
have joined forces to deli
ver customized solutions. This results in a
streamlined, highly useable, and more dynamic product for their
customers, and thus a richer and more satisfying experience. For
example, a bookseller and a toy retailer present dynamic shipping
information (pr
ovided by the delivery company) on their own web site.
The end user can view the shipping information with a click of the
mouse, rather than having to take the order number from the seller’s
web site, navigating to the shipper’s web site, plugging in the
number and then finally receiving the shipping information.

Such systems stress the increasing need for interactions between
systems operated by different companies and potentially operating on
different platforms that need to collaborate to prese
nt meaningful
content to the end user. One system in this situation provides the
other with a service that can be called to accomplish a certain task on
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


the host system. Thus we see the Web transforming from static web
pages to dynamic web pages, and now

evolving to interactive Web
services. This would very well address the two leading concerns of
Internet businesses today, i.e. satisfying the ever
increasing demands
of the users for useful web content and the need for integrating
heterogeneous informati
on systems in satisfying these needs.


Simplified Object Access Protocol (SOAP) is a specification that enables
applications to communicate with other applications. It provides a
framework for connecting Web sites and applications to creat

These Web services link different sites and applications
together to perform functions that the individual components or sites
are not capable of. SOAP provides a mechanism by which each service
can expose its features and communicate wit
h other services.

Using SOAP, one can link services offered by different systems
together as components and use these components to build a complex
information system application in a much shorter timeframe. For
example, using SOAP one can build a site
where football fans can go to
view the status of different football games. On this site the weather
information for the various games can be provided by one Web service
(such as the Weather channel), the schedules and scores can be
provided by another ser
vice (such as the NFL), the directions to the
game can be provided by yet another service (such as MapQuest) and
live commentary for the game can be broadcast using a media player
and streamed audio from one of the local radio stations. All this
on can be presented seamlessly to the user on one page
without the user being aware that so many different systems
(companies) are collaborating to bring the information to the user.

SOAP suggests the use of a specific message format in Extensible
Language (XML) and a message transport protocol such as
Hypertext Transfer Protocol (HTTP). Using SOAP, different systems
communicate with each other by passing text messages encoded as
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


XML, that are then communicated over a transport protocol such as

Figure 1 and its explanation is taken from the article “SOAP: Simple
Object Access Protocol” by William Bordes and Johann Dumser. It
shows a high level diagram of how SOAP is used to execute a
distributed task.


Level diagram of SOAP i
n a distributed system.


Station1 executes a command which creates an action on the associated
application server.


This command generates a process within the application and the result arrives in
the application interface.


The message is translated into X
ML format by the implementation and is then
sent to the Web server.


The XML parser checks the coherence of the XML document and sends the SOAP
message via HTTP.


The XML parser checks the validity of the message using the HTTP and XML
headers, and accepts
or rejects it.


The message is then routed to the relevant application server and translated by
the implementation so that the task is meaningful for the application. The SOAP
application which receives the SOAP message must proceed as follows to
the message:

Identify the parts of the SOAP message which correspond to the

Check that all the mandatory parts of are supported by the application or
discard the message

Remove all the parts before transferring he message if the application i
not the endpoint


The application then executes the task. A result is produced.


The return is done in the same way: implementation and then sending by HTTP.


The result of the action may be different: display in a browser, actions, access to
a database,
and so on.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


SOAP is a specification rather than an implementation, therefore what
is presented here adheres to the latest specification of SOAP and may
not hold true in the future as the specification evolves. In the original
SOAP specification two major

design goals were identified. These were
as follows:

“Provide a standard object invocation protocol built on Internet
standards, using HTTP as the transport and XML for data

“Create an extensible protocol and payload format that can

he latest SOAP specification (1.1) simply states:

“A major design goal for SOAP is simplicity and extensibility.”

Microsoft one of the proponents of SOAP has heavily invested in this
technology. The vision is that one
day developers will expose their
lications (referred to as Web services) over the web. Clients will be
able to call these applications from their own web pages to integrate
data provided by these applications. This will increase code
reuse and
decrease the time and money required to bui
ld complex applications.

Advantages of SOAP

Some advantages of using SOAP are

SOAP is an open standard that is built upon open technologies such
as XML and HTTP. It is not vendor
specific and therefore less
intimidating to smaller players in the industr
y. As a result it is
being accepted uniformly by the industry, thus improving its
chances of being the de
facto standard for true distributed

SOAP by design provides interoperability between heterogeneous
operating systems. Using SOAP
systems using different operating
systems such as UNIX, Macs, Mainframes, Windows etc. can be
integrated to build integrated solutions.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Even though the initial systems for SOAP were built using HTTP as
the transport protocol, SOAP can be used over any othe
r protocol.
The SOAP specification does not mandate any particular transport
protocol. This gives SOAP the opportunity to consolidate various
protocols such as IIOP and RMI into a single specification, thus
improving usability and interoperability.

P based systems are very easy to deploy. They require
minimal amount of setup and the enabling of a port for the
transport protocol being used.

SOAP based distributed systems are loosely
coupled. As a result
they are easier to maintain because they can b
e modified
independently of other systems.

Unless major serialization changes are made to the SOAP
specification in the future, the applications that are written will not
be negatively impacted.

When used over HTTP protocol, SOAP packets can easily bypas
firewalls if their content is not deemed malicious. This is a major
limitation in competing distributed protocols which are not firewall

Disadvantages of SOAP

SOAP has the following disadvantageous:

SOAP’s relied on HTTP for transport of XM
L data in the version 1.0
of its specification. HTTP requires a stateless request/response
architecture that is not appropriate under all circumstances. While
one can work around the state problem it requires additional

All SOAP data is serialize
d and passed by value and currently there
is no provision for passing data by reference. This could lead to
synchronization problems if multiple copies of the same object are
being passed at the same time.

Since SOAP is a protocol, not a system, it does n
ot address
security. While it is very desirable to bypass the firewall woes
experienced by competing distributed architectures, it is imperative
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


that the security concerns around SOAP be resolved before it can
be expected to gain predominance in the marke


While comparing SOAP with other commonly used distributed
technologies one must keep in mind that SOAP is a protocol rather
than a complete distributed architecture. This technology is still in its

and as a result most of the systems that implement this
technology do not explore the full potential it has to offer. SOAP is
compatible with most of the aspects of distributed computing, but the
implementation of some of these aspects is outside the sco
pe of a wire

There are several considerations that go into selecting a distributed
architecture. Some of the important ones are scalability, performance,
state management, garbage collection and security. Table 1 shows
how SOAP compares with

the common distributed architectures based
on these criteria.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog







General Inter
Protocol (GIOP)

Object Remote Procedure
Call (ORPC)


Any transport


Corba uses stateful
programming model
which is not as

Least scalable. Clients
ping the server at regular
intervals to ascertain that
it is still available. This
pinging process limits
scalability when large # of
connections are involved.

Relatively scalable. Uses
RMI Registry whic
h could
limit scalability if it is
located on one server.

Most scalable of the


Once an object
reference is obtained,
CORBA permits
direct client
Hence subsequent
communication is
very fast.

Requires several round
trips to activate and use
the remote object. Once
object’s reference is
obtained, direct object
access without DCOM can
take place from client.

Good performance.
Works for Java language
only and hence is fine
tuned for it.

Currently low.
Overhead of
tracting SOAP
envelope, parsing
XML, creating
appropriate objects
and converting



and stateful.

Provides location
transparency. Is stateful.

Very flexible. Provides
both stateful and stateless

Not addressed by
the protocol used, it is


CORBA does not
address distributed
memory management.

Provides automatic
garbage collection using
the pinging mechanism
ssed earlier.

Excellent garbage

SOAP does not
address garbage


No intrinsic support
for authentication,
authorization or

Very security
Provides support for
authorization or identity.

User can set appropriate
level of security.

Since Java RMI works
with java programming
language it inherits the
security built into Java.
Use of RMI Security
Manager can enable
dynamic class loading
thus providing additional

Since SOAP is a w
protocol, it does not
address security.
Security is
determined by the
transport protocol that
it uses. For example,
HTTPS using secured
socket layer (SSL)
when HTTP is the
transport protocol.

Table 1. Comparison of SOAP with other Distributed Archi

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


It can be seen from this table that SOAP fares very well in most areas
when compared to the other technologies. Considering the fact that
SOAP is such a new technology and is still evolving, this comparison is
quite impressive and very promising

XML the building block of SOAP

XML can be considered the building block of SOAP. SOAP is the
technology that is taking XML ‘out

process’. However, SOAP is not
the only distributed technology that uses XML as its foundation.
Several other proto
cols for executing Remote Procedure Calls (RPC)
using XML already exist. SOAP outshines the other protocols because
it provides a standard way of executing RPC using XML.

Some of the other XML approaches are as follows:


This protocol serializ
es RPC requests and responses into XML
documents, which are transmitted across a HTTP connection between
the client and the server. SOAP originally started out as XML
before additional features were added to it. In fact Dave Winter of
Userland Corpora
tion, one of the original people responsible for SOAP,
was also the designer of XML
RPC. SOAP however is far richer than
RPC as it offers support for namespaces, longer element names,
XML Schemas, enumerations, arrays, and custom types.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog




Metadata Object Persistence (XMOP) is a protocol that allows
interoperation between various object technologies such as Java on
different platforms, Microsoft COM and CORBA. To use XMOP
developers write XML based serialization for their classes. This is

achieved by implementing the s

interface in Java and
IPersist interface in Microsoft COM/DCOM. Using these XML files
objects can be marshalled between different object systems such as
COM/DCOM, CORBA and Java on various platforms.


Electronic Business XML (ebXML) is a more ambitious standard for
sharing information between businesses. It uses messaging containing
XML documents to transfer data between business systems. It is
much larger in scope than SOAP because it encompasses th
e following

Envelope and headers for messages/documents

Reliable messaging and error handling

Message routing


Audit trails

Quality of service

Platform independence

Restart and recovery

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


In March, 2001 ebXML under pressure from the devel
communities to include the works of other initiatives, agreed to use
SOAP for a part of its infrastructure.

SOAP Architecture

Figure 2 shows the overall architecture of a generic system built using
SOAP. This system uses HTTP protocol to pass t
he SOAP message
between the client and the server. The client application calls a client
side proxy object using its native RPC protocol (such as COM for
Microsoft platform and CORBA for UNIX). The proxy object uses an
XML parser to convert the call into

a SOAP packet. This SOAP packet
is then transmitted over the Internet/Intranet to the web server using
the HTTP protocol. The Web server handles the URL connection point
of the remote service, and launches a SOAP translator which may be
an ASP page, an I
SAPI extension, a CGI program, a Perl script, etc.
This translator uses a local XML parser to parse out the object name,
method name and parameter values from the SOAP package. It uses
these values to call the particular method of the server object by the

local ORPC protocol, and packages the results into a response SOAP
packet. This response is unpackaged by the proxy and presented to
the client.

Figure 2 SOAP Architecture

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Now that we have a high level understanding of the SOAP architecture
we can d
elve into the specifics of this architecture.

In version 1.0 of SOAP HTTP protocol was mandatory. This
requirement was relaxed to cover all protocols such as HTTP, FTP, and
SMTP in the version 1.1 of the specification. If HTTP protocol is used,
an HT
TP request message needs to be created by the calling process
and sent to the called process using HTTP POST or M

SOAP requires calls to use proper XML syntax. SOAP recommends that
namespaces be used because they provide a mechanism to scope
ents and attributes to various contexts. The namespace
org:soap.v1’ is the proposed namespace value
for SOAP. Within a SOAP payload it uses the id/href attribute pairs to
distinguish between unique entities. This provides the abilit
y to multi
reference elements in the request and response payloads, such that an
element that is serialized may be referenced as many times as

SOAP Payload

Figure 3 shows the SOAP payload structure. The

is the first
element in a SO
AP message. It encapsulates the various parts of the
message and identifies it as a SOAP message.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Figure 3 The SOAP Payload

The envelope uses namespace URIs to specify the version information
and the encoding rules.

The envelope is followed by the

element. It contains
extended information about the message such as authorization or
transaction information.

Next comes the Body element which contains the application
data. In the listing 1 below the SOAP Body represents a
procedure call to CheckAccount. Encoding rules describe the syntax
used to encode data in the body.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog







<v:From SOAP:mustUnderstand='1'>









Listing 1 A SOAP Envelope

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Transports and RPC

As mentioned earlier SOAP messages do not need a specific transport
protocol. An overwhelming majority of developers prefer HTTP
protocol for the following reasons:

HTTP is available on all plat

It requires little runtime support

It uses few or no packets to maintain sessions

It is very firewall friendly

As a result most of the SOAP implementations are done using XML
over the HTTP protocol. Therefore, we will be looking at the HTTP
ort mechanism only in this section.

The SOAP architecture matches very well with the HTTP request
response model. SOAP requests are transported in a HTTP POST or
POST and the SOAP response is sent back in HTTP response.

The Content
Type of the SO
AP message is set to "text/xml". An
additional HTTP header SOAPAction helps identify incoming SOAP
requests to firewalls. The child element of the Body represents a
method call, and the child elements of the call are parameters. The
convention is to use
the method name for the request payload and
method name + "Response" for the response (ex. Add &
AddResponse). For the response, the specification states that the
return value must appear as the first child element of the payload, and
that it's name is not

important (you know it by its position, not its

Listing 2 and 3 represent an example of the request and response
messages respectively generated by a SOAP call.

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog




Accept: text/*

type: text

length: nnnn

SOAPAction: the





<m:FindPart xmlns:m="the






Listing 2 Request message generated by a SOAP call

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


HTTP/1.1 200 OK

Server: Microsoft

Date: Wed, 31 Jan 2001 07:21:19 GMT

eType: CallResponse

Length: nnn

Type: text/xml

Expires: Wed, 31 Jan 2001 07:21:20 GMT

control: private

<?xml version="1.0"?>





< m:FindPartResponse xmlns:m="the

<PartName>Fan Belt #18</PartName>




Listing 3 Response message generated by a SOAP c

Industry Acceptance

As mentioned earlier, SOAP evolved out of XML
RPC protocol designed
by Dave Winer of UserLand, for doing RPC over HTTP using XML. SOAP
1.0 was released in September 1999 as a joint effort of Don Box of
DevelopMentor, and several

engineers from Microsoft. It was not very
well received by IBM and Sun, who were working on a similar but more
ambitious effort called ebXML. For SOAP to be successful as an
interoperability protocol, the acceptance of big players like IBM and
Sun was c

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Fortunately, IBM changed its mind and became one of the key players
in the development of the SOAP 1.1 specification of April 2000.
Proving its strong support of SOAP, IBM released a reference
implementation of SOAP for Java (SOAP4J) in May 20
00. IBM later
donated its SOAP4J reference implementation to Apache Software
Foundation's XML Project, which has created the Apache
implementation based on the toolkit. Microsoft’s Web Services Toolkit
(renamed the SOAP Toolkit) was released in June
2000. Sun initially
held back its support of SOAP stating that it would support whatever
the W3C finally recommended. In early June 2000 shortly after the
release of the Microsoft SOAP Toolkit, Sun announced that it would, in
fact, support SOAP.

t of the largest three software companies in the world gave
SOAP a great chance of succeeding. The support of developers and
smaller companies has also been instrumental in shaping SOAP. SOAP
has enjoyed the support of IONA, one of the largest vendors of

products and RogueWave another well
known CORBA vendor. SOAP’s
commitment to backward compatibility has helped retain the loyalty of
the original XML
RPC community. ObjectSpace, a leading B2B provider
has incorporated SOAP in its Software solutions

In September 2000 the Object Management Group announced that it
had ‘initiated work on a standard that will integrate the new protocol
SOAP with OMG's CORBA architecture’.

Since the start of the year 2001, interest in SOAP has intensified.
Apache re
leased SOAP Version 2.1 with enhanced support for the
protocol. In January 2001,
WebMethods, Microsoft and HP submitted
SOAP 1.1 Extension to W3C which adds functionality for implementing
more efficient B2B transactions. In February 2001,
IBM and Microso
submitted SOAP Security Extensions. Later that month the team
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


working on ebXML announced that it would integrate SOAP into its

In March 2001 IBM alphaWorks announced the release of the TSpaces
Services Suite which offers a development
toolkit "to assist the
creation, discovery, and integration of Web services. It is based in
standards for discovery (UDDI), description (WSDL), and invocation
(SOAP) of Web services.

In April 2001 Microsoft updated the version 2.0 SOAP Toolkit and the
Web Services Description Language (WSDL). Using these developers
can build high
performance, commercial
quality XML Web Services.
Microsoft also announced that Windows XP would have native support
for SOAP.

Finally, Microsoft’s new development platfor
m the ‘.NET platform’
allows one to create SOAP extensions. These extensions allow
developers to create very interesting applications on top of the core
SOAP architecture found within .NET. Using SOAP extensions one can
add functionality such as encrypti
on, compression, and SOAP

Implications for the IS Professionals

On the face of it SOAP just appears to be an XML wrapper around
procedure calls to help client programs communicate with servers
(through firewalls) across the Internet. How
ever, if one digs deeper
one can see that it presents a new paradigm in software development.
Using SOAP developers will be able integrate their code with various
services (hereafter called Web services) from one or more vendors to
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


create the desired cust
om software solution. This would have several
benefits both for the Web service consumer and Web service
developer. Figure 4 displays a travel agency reservation system that
uses Web services offered by a Hotel, Airline and a Rental car
company systems.

Figure 4 A Travel Agency reservation system that uses Web services
offered by a Hotel, Airline and a Rental car company systems.

From the consumer perspective, this would enhance code
reuse within
and outside of organizations thus eliminating the need fo
r writing
custom code and re
inventing the wheel. Since Web services will not
be tied to a particular language and platform, the consumer will be
able to pick and choose, mix and match Web services offered by
various vendors. As a result, fewer developer
s will be required to
develop large custom systems thus reducing software development

Under this structure the providers of Web Services will be responsible
for maintaining their code and posting updates to them behind the
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


scenes. Assuming that th
e vendors offering the Web services will be
domain matter experts in their area, the risk associated with the
development effort (of that particular part of the software) will be
lowered. This would eliminate potential configuration issues, which are

prominent in component
based systems. It would also improve
the reliability of the software because companies will be able to
‘borrow from the experiences of other companies’ who are using the
same service from the vendor. The TCO (Total Cost of Ownersh
ip) of
the Web Services for the consumers will be much lower that if because
the vendor will be solely responsible for that part of the application.

From the Web service provider’s perspective this would have several
benefits as well. The providers will

be able to choose their own
development platform and language. They could in
turn incorporate
Web services seamlessly into their own Web services thus speeding up
their development time and improving the richness of their product
offerings. Finally, unl
ike components Web services will never have to
be ported to a different platform.

SOAP has created a case for itself in distributed computing. IS
professionals should make an effort to educate themselves about this
technology. It has the potential to

revolutionize the way software
development is done. Realizing that IS professionals should dedicate
some research and development effort in this area. Fortunately, most
of the tools for SOAP are available for free, therefore time time and
energy is the
only investment required.

Finally, a note of caution, SOAP is not an official standard yet. W3C is
still working on that. It lacks some of the tools common in other
distributed systems such as CORBA and DCOM. It does not support
oriented concep
ts such as inheritance and transactions. It is
much slower than DCOM or CORBA. Despite all these factors a case
can still be made for the use of SOAP for distributed systems where
cost restrictions prohibit the use of CORBA (CORBA ORB is very
Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


, non
Microsoft platform prohibits the use of DCOM and
maintaining current network infrastructure is essential.


Barish, Greg, “Untangling the Web: SOAP uses XML as a simple and
elegant solution that automates B2B transactions ”, Intelligent
Enterprise Volume 4 Number 5, March 27, 2001,


Borden, Jonathan, “XML Metadata Object Persistence”, URL:

Bordes, William and Dumser, Johann, “SOAP: Simple Object Access
Protocol”, URL:

Box, Don, “A Young P
erson's Guide to The Simple Object Access
Protocol: SOAP Increases Interoperability Across Platforms and
Languages”, MSDN Magazine, March, 2000, URL:

Brown, Kent, “DNA 2000: Opening New Windows”, Enterprise
Development, November 1999,


Brown, Kent, “SOAP for Platform
Neutral Interoperability”, XML
Magazine, Fall 2000,


Cover, Robin, “Simple Object Access Protocol (SOAP)”,


Hudson, Michael and Miller, Craig, “IT and the NOW Econom
y: XML
technologies can provide more options and flexibility in enterprise
messaging”, Intelligent Enterprise Volume 4 Number 2, January 30,
2001, URL:

Simplified Obje
ct Access Protocol (SOAP)

CIS 679 Management Of IS

by Inder Nandrajog


Lerner, Reuven M., “At the Forge: Introducing SOAP”, Linux Journal
Volume 2001 Issue 83s, March, 2001.

Loshin, Pete, “Web Services and the Simple Object Access Protocol”,

Marcato, Davide, “Distributed computing with SOAP”, URL:

Marchal, Benoît,
"Soapbox: Why I'm using SOAP. One developer tells
why he's feeling sold on SOAP."
, IBM DeveloperWorks XML Library,
February 2001,


Modi, Tarak,
"Clean up Your Wire Protocol with SOAP, Part 1. An
Introduction to The Basics of SOAP. [Wire Protocol.]"
, JavaWorld,
March 2001, URL:

Scribner, Kennard, Stiver, Mark C. and Scribner, Kenn, “Understanding
SOAP: The Authoritative Solution”, Indiana: Sams Publishing, 2000.

hohoud, Yasser, “Create Firewall
Friendly distributed Apps”, URL:

Skonnard, Aaron, “SOAP”, MIND, January 2000,


“SOAP Frequently Asked Questions”, URL:

“SOAP Specification: Simple Object Access Protocol (SOAP) 1.1”, Ma
8, 2000, URL:

Sun White paper, “An Open Architecture for Interoperable, Smart Web
Services”, URL:

“SOAP's Value Proposition”, URL: