SOAP Architecture - Njit

squabbletownmushySoftware and s/w Development

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

86 views

Simplified Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
1

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 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
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 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


Page
2

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.



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 creat
e
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 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
informati
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
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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
3

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


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 i
n 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 X
ML 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 i
s
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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
4


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.”


T
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
app
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
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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
5



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.



SOA
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
s
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 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
coding.



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


Page
6

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


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 sco
pe 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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
7



CORBA

DCOM

JAVA
-
RMI

SOAP

Protocol
Name

General Inter
-
ORB
Protocol (GIOP)

Object Remote Procedure
Call (ORPC)

JRMP

Any transport
protocol.

Scalability

Corba uses stateful
programming model
which is not as
scalable.

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
four.

Performance

Once an object
reference is obtained,
CORBA permits
direct client
-
server
communication.
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
ex
tracting SOAP
envelope, parsing
XML, creating
appropriate objects
and converting
parameters.

State
Mgmt.

Connection
-

oriented
and stateful.

Provides location
transparency. Is stateful.

Very flexible. Provides
both stateful and stateless
sub
-
protocols.

Not addressed by
SOAP. If HTTP is
the protocol used, it is
stateless.

Garbage
collection

CORBA does not
address distributed
memory management.
Vendor
-
specific
implementations
exist.

Provides automatic
garbage collection using
the pinging mechanism
discu
ssed earlier.

Excellent garbage
collection

SOAP does not
address garbage
collection.

Security

No intrinsic support
for authentication,
authorization or
identity.

Very security
-
oriented.
Provides support for
authentication,
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
security.

Since SOAP is a w
ire
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
tectures

Simplified Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
8

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 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:



XML
-
RPC


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
-
RPC
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
XML
-
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


Page
9

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 s
erializable

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 th
e 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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
10

In March, 2001 ebXML under pressure from the devel
opment
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


Page
11


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
-
POST.



SOAP requires calls to use proper XML syntax. SOAP recommends that
namespaces be used because they provide a mechanism to scope
elem
ents 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 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
necessary.



SOAP Payload



Figure 3 shows the SOAP payload structure. The
Envelope

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


Page
12


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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
13


<SOAP:Envelope


xmlns:SOAP='http://schemas.xmlsoap.org/soap/envelope/'


SOAP:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'


xmln
s: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:En
velope>



Listing 1 A SOAP Envelope



Simplified Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
14

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
forms



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
transp
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
HTTP M
-
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
name).



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


Page
15


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 Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
16



HTTP/1.1 200 OK

Server: Microsoft
-
IIS/5.0

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

Messag
eType: 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 c
all



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
ritical.

Simplified Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
17



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
-
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.



Suppor
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

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 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
ft
submitted SOAP Security Extensions. Later that month the team
Simplified Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
18

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 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
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. 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


Page
19

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
costs.



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


Page
20

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
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 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
object
-
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


Page
21

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 P
erson's Guide to The Simple Object Access
Protocol: SOAP Increases Interoperability Across Platforms and
Languages”, MSDN Magazine, March, 2000, URL:
http://msdn.microsoft.com/msdnma
g/issues/0300/soap/soap.asp


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

URL:
http://www.devx.com/upload/free/features/en
tdev/1999/11nov99/cv1
199/cv1199.asp


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

URL:
http://www.xmlmag.com/upload/free/fe
atures/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 Econom
y: XML
technologies can provide more options and flexibility in enterprise
messaging”, Intelligent Enterprise Volume 4 Number 2, January 30,
2001, URL:
http://www.intelligententerprise.c
om/010130/feat1.shtml

Simplified Obje
ct Access Protocol (SOAP)


CIS 679 Management Of IS

by Inder Nandrajog


Page
22

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
-
soapb
x1.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.


S
hohoud, 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”, Ma
y
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