Simplified Object Access Protocol
Inder Nandrajog
CIS 679 Management of IS
Spring, 2001
INTRODUCTION
Over the last few years information systems have been revolutionized
by the explosive popularity of the Internet. The Web has completely
transformed 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 capitalize 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 deliver 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 (provided 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 order
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 present 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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 1
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 information systems in satisfying these needs.
WHAT IS SOAP
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 create Web
services. 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 with 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 service (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
information 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
Markup 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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 2
XML, that are then communicated over a transport protocol such as
HTTP.
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.
FIGURE 1– High-Level diagram of SOAP in a distributed system.
1) Station1 executes a command which creates an action on the associated
application server.
2) This command generates a process within the application and the result arrives in
the application interface.
3) The message is translated into XML format by the implementation and is then
sent to the Web server.
4) The XML parser checks the coherence of the XML document and sends the SOAP
message via HTTP.
5) The XML parser checks the validity of the message using the HTTP and XML
headers, and accepts or rejects it.
6) 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
translate the message:
 Identify the parts of the SOAP message which correspond to the
application
 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 is
not the endpoint
7) The application then executes the task. A result is produced.
8) The return is done in the same way: implementation and then sending by HTTP.
9) The result of the action may be different: display in a browser, actions, access to
a database, and so on.
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 3
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
encoding.”
“Create an extensible protocol and payload format that can
evolve.”
The 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
applications (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 build 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 industry. As a result it is
being accepted uniformly by the industry, thus improving its
chances of being the de-facto standard for true distributed
interoperability.

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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 4

Even though the initial systems for SOAP were built using HTTP as
the transport protocol, SOAP can be used over any other 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.

SOAP 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 be 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 bypass
firewalls if their content is not deemed malicious. This is a major
limitation in competing distributed protocols which are not firewall
friendly.
Disadvantages of SOAP
SOAP has the following disadvantageous:

SOAP’s relied on HTTP for transport of XML 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
coding.

All SOAP data is serialized 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 not address
security. While it is very desirable to bypass the firewall woes
experienced by competing distributed architectures, it is imperative
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 5
that the security concerns around SOAP be resolved before it can
be expected to gain predominance in the marketplace.
SOAP AND OTHER DISTRIBUTED TECHNOLOGIES
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
infancy 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 scope of a wire
protocol.
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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 6
JAVA-RMI
Object Remote Procedure
JRMP
Call (ORPC)
SOAP
Any transport
protocol.
Scalability
General Inter-ORB
Protocol (GIOP)
DCOM
Least scalable. Clients
ping the server at regular
Corba uses stateful
Relatively scalable. Uses
intervals to ascertain that
programming model
RMI Registry which could Most scalable of the
it is still available. This
which is not as
limit scalability if it is
four.
pinging process limits
scalable.
located on one server.
scalability when large # of
connections are involved.
Performance
Protocol
Name
CORBA
Once an object
reference is obtained,
CORBA permits
direct client-server
communication.
Hence subsequent
communication is
very fast.
Not addressed by
Very flexible. Provides
Connection - oriented Provides location
SOAP. If HTTP is
both stateful and stateless
and stateful.
transparency. Is stateful.
the protocol used, it is
sub-protocols.
stateless.
CORBA does not
address distributed Provides automatic
memory management. garbage collection using
Vendor-specific
the pinging mechanism
implementations
discussed earlier.
exist.
Security
State
Mgmt.
Currently low.
Overhead of
extracting SOAP
envelope, parsing
XML, creating
appropriate objects
and converting
parameters.
Garbage
collection
Requires several roundtrips to activate and use
Good performance.
the remote object. Once
Works for Java language
object’s reference is
only and hence is fineobtained, direct object
tuned for it.
access without DCOM can
take place from client.
No intrinsic support
for authentication,
authorization or
identity.
SOAP does not
address garbage
collection.
Excellent garbage
collection
Since Java RMI works
with java programming
Very security-oriented.
language it inherits the
Provides support for
security built into Java.
authentication,
Use of RMI Security
authorization or identity.
Manager can enable
User can set appropriate
dynamic class loading
level of security.
thus providing additional
security.
Since SOAP is a wire
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 Architectures
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 7
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-of- process’. However, SOAP is not
the only distributed technology that uses XML as its foundation.
Several other protocols 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:
XML-RPC
This protocol serializes 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-RPC
before additional features were added to it. In fact Dave Winter of
Userland Corporation, one of the original people responsible for SOAP,
was also the designer of XML-RPC. SOAP however is far richer than
XML-RPC as it offers support for namespaces, longer element names,
XML Schemas, enumerations, arrays, and custom types.
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 8
XMOP
XML 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 serializable 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.
EbXML
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 the following
features:

Envelope and headers for messages/documents

Reliable messaging and error handling

Message routing

Security

Audit trails

Quality of service

Platform independence

Restart and recovery
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 9
In March, 2001 ebXML under pressure from the development
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 the SOAP message
between the client and the server. The client application calls a clientside 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 ISAPI 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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 10
Now that we have a high level understanding of the SOAP architecture
we can delve 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 HTTP request message needs to be created by the calling process
and sent to the called process using HTTP POST or M-POST.
SOAP requires calls to use proper XML syntax. SOAP recommends that
namespaces be used because they provide a mechanism to scope
elements and attributes to various contexts. The namespace
‘urn:schemas-xmlsoap-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 ability to multireference elements in the request and response payloads, such that an
element that is serialized may be referenced as many times as
necessary.
SOAP Payload
Figure 3 shows the SOAP payload structure. The Envelope is the first
element in a SOAP message. It encapsulates the various parts of the
message and identifies it as a SOAP message.
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 11
Envelope
Header
Extended Information
Body
Method Element
Embedded Elements
Other Independent
Elements
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 optional Header element. It contains
extended information about the message such as authorization or
transaction information.
Next comes the Body element which contains the application-specific
data. In the listing 1 below the SOAP Body represents a remote
procedure call to CheckAccount. Encoding rules describe the syntax
used to encode data in the body.
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 12
<SOAP:Envelope
xmlns:SOAP='http://schemas.xmlsoap.org/soap/envelope/'
SOAP:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'
xmlns:v='http://www.vbxml.com/soapworkshop/'>
<SOAP:Header>
<v:From SOAP:mustUnderstand='1'>
cdix@soapworkshop.com
</v:From>
</SOAP:Header>
<SOAP:Body>
<v:CheckAccount>
<ssn>123-456-7890</ssn>
</v:CheckAccount>
</SOAP:Body>
</SOAP:Envelope>
Listing 1 A SOAP Envelope
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 13
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 platforms

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
transport mechanism only in this section.
The SOAP architecture matches very well with the HTTP requestresponse model. SOAP requests are transported in a HTTP POST or
HTTP M-POST and the SOAP response is sent back in HTTP response.
The Content-Type of the SOAP 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
name).
Listing 2 and 3 represent an example of the request and response
messages respectively generated by a SOAP call.
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 14
POST /PartServer.pl HTTP/1.1
Host: www.mcp.com
Accept: text/*
Content-type: text/xml
Content-length: nnnn
SOAPAction: the-method-uri#FindPart
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:FindPart xmlns:m="the-method-uri">
<PartNo>12345</PartNo>
<GroupID>7</GroupID>
</m:FindPart>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listing 2 Request message generated by a SOAP call
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 15
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 31 Jan 2001 07:21:19 GMT
MessageType: CallResponse
Content-Length: nnn
Content-Type: text/xml
Expires: Wed, 31 Jan 2001 07:21:20 GMT
Cache-control: private
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
< m:FindPartResponse xmlns:m="the-method-uri">
<PartName>Fan Belt #18</PartName>
</vb:GetSecretIdentityResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listing 3 Response message generated by a SOAP call
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 critical.
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 16
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 2000. IBM later
donated its SOAP4J reference implementation to Apache Software
Foundation's XML Project, which has created the Apache-SOAP
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.
Support 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 CORBA
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 released 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 Microsoft
submitted SOAP Security Extensions. Later that month the team
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 17
working on ebXML announced that it would integrate SOAP into its
specification.
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 platform 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 encryption, compression, and SOAP
attachments.
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. However, 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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 18
create the desired custom 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.
Airline
Web Service
Hotel
Web Service
Rental Car
Web Service
Travel Agency
Reservation
System
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 for 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 developers will be required to
develop large custom systems thus reducing software development
costs.
Under this structure the providers of Web Services will be responsible
for maintaining their code and posting updates to them behind the
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 19
scenes. Assuming that the 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
very 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 Ownership) 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, unlike 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
object-oriented concepts 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 Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 20
expensive), non-Microsoft platform prohibits the use of DCOM and
maintaining current network infrastructure is essential.
Bibliography
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,
URL: http://www.intelligententerprise.com/010327/feat2_1.shtml
Borden, Jonathan, “XML Metadata Object Persistence”, URL:
http://www.openhealth.org/documents/XMOP.htm
Bordes, William and Dumser, Johann, “SOAP: Simple Object Access
Protocol”, URL:
http://www.techmetrix.com/trendmarkers/tmk1200/tmk1200-3.php3
Box, Don, “A Young Person's Guide to The Simple Object Access
Protocol: SOAP Increases Interoperability Across Platforms and
Languages”, MSDN Magazine, March, 2000, URL:
http://msdn.microsoft.com/msdnmag/issues/0300/soap/soap.asp
Brown, Kent, “DNA 2000: Opening New Windows”, Enterprise
Development, November 1999,
URL:
http://www.devx.com/upload/free/features/entdev/1999/11nov99/cv1
199/cv1199.asp
Brown, Kent, “SOAP for Platform-Neutral Interoperability”, XML
Magazine, Fall 2000,
URL:
http://www.xmlmag.com/upload/free/features/xml/2000/04fal00/kb00
04/kb0004.asp
Cover, Robin, “Simple Object Access Protocol (SOAP)”,
URL: http://www.xml.coverpages.org/soap.html
Hudson, Michael and Miller, Craig, “IT and the NOW Economy: XML
technologies can provide more options and flexibility in enterprise
messaging”, Intelligent Enterprise Volume 4 Number 2, January 30,
2001, URL: http://www.intelligententerprise.com/010130/feat1.shtml
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 21
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”,
URL: http://msdn.microsoft.com/xml/general/soap_webserv.asp
Marcato, Davide, “Distributed computing with SOAP”, URL:
http://www.devx.com/upload/free/features/vcdj/2000/04apr00/dm04
00/dm0400.asp
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,
URL:http://www-106.ibm.com/developerworks/library/x-soapbx1.html
Modi, Tarak, "Clean up Your Wire Protocol with SOAP, Part 1. An
Introduction to The Basics of SOAP. [Wire Protocol.]", JavaWorld,
March 2001, URL:
http://www.vbxml.com/soapworkshop/articles/intro/default.asp
Scribner, Kennard, Stiver, Mark C. and Scribner, Kenn, “Understanding
SOAP: The Authoritative Solution”, Indiana: Sams Publishing, 2000.
Shohoud, Yasser, “Create Firewall-Friendly distributed Apps”, URL:
http://www.devx.com/upload/free/features/vbpj/2000/10oct00/ys001
0/ys0010.asp
Skonnard, Aaron, “SOAP”, MIND, January 2000,
URL: http://www.microsoft.com/mind/0100/soap/soap.asp
“SOAP Frequently Asked Questions”, URL:
http://www.develop.com/soap/soapfaq.htm
“SOAP Specification: Simple Object Access Protocol (SOAP) 1.1”, May
8, 2000, URL: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
Sun White paper, “An Open Architecture for Interoperable, Smart Web
Services”, URL: http://www.sun.com/software/sunone/wp-arch/
“SOAP's Value Proposition”, URL:
http://www.soapwebservices.com/articles/soap_value_proposition.asp
Simplified Object Access Protocol (SOAP)
by Inder Nandrajog
CIS 679 Management Of IS
Page 22