soap

Document Sample
soap Powered By Docstoc
					                  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)                 CIS 679 Management Of IS
by Inder Nandrajog                                                        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)           CIS 679 Management Of IS
by Inder Nandrajog                                                  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)                     CIS 679 Management Of IS
by Inder Nandrajog                                                            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)             CIS 679 Management Of IS
by Inder Nandrajog                                                    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)              CIS 679 Management Of IS
by Inder Nandrajog                                                     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)            CIS 679 Management Of IS
by Inder Nandrajog                                                   Page 6
 Protocol             CORBA                       DCOM                    JAVA-RMI                      SOAP


                 General Inter-ORB        Object Remote Procedure                                Any transport
                                                                  JRMP
 Name

                 Protocol (GIOP)          Call (ORPC)                                            protocol.



                                     Least scalable. Clients
                                     ping the server at regular
                 Corba uses stateful                             Relatively scalable. Uses
   Scalability




                                     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.

                 Once an object                                                                  Currently low.
                                          Requires several round-
                 reference is obtained,                                                          Overhead of
                                          trips to activate and use
   Performance




                 CORBA permits                                      Good performance.            extracting SOAP
                                          the remote object. Once
                 direct client-server                               Works for Java language      envelope, parsing
                                          object’s reference is
                 communication.                                     only and hence is fine-      XML, creating
                                          obtained, direct object
                 Hence subsequent                                   tuned for it.                appropriate objects
                                          access without DCOM can
                 communication is                                                                and converting
                                          take place from client.
                 very fast.                                                                      parameters.

                                                                                              Not addressed by
                                                                  Very flexible. Provides
 Mgmt.




                 Connection - oriented Provides location                                      SOAP. If HTTP is
                                                                  both stateful and stateless
 State




                 and stateful.         transparency. Is stateful.                             the protocol used, it is
                                                                  sub-protocols.
                                                                                              stateless.

                 CORBA does not
                 address distributed Provides automatic
                                                                                                 SOAP does not
 collection
 Garbage




                 memory management. garbage collection using        Excellent garbage
                                                                                                 address garbage
                 Vendor-specific     the pinging mechanism          collection
                                                                                                 collection.
                 implementations     discussed earlier.
                 exist.
                                                                                                 Since SOAP is a wire
                                                                     Since Java RMI works        protocol, it does not
                                                                     with java programming       address security.
                                          Very security-oriented.
                                                                     language it inherits the    Security is
                 No intrinsic support     Provides support for
                                                                     security built into Java.   determined by the
                 for authentication,      authentication,
                                                                     Use of RMI Security         transport protocol that
                 authorization or         authorization or identity.
                                                                     Manager can enable          it uses. For example,
                 identity.                User can set appropriate
   Security




                                                                     dynamic class loading       HTTPS using secured
                                          level of security.
                                                                     thus providing additional   socket layer (SSL)
                                                                     security.                   when HTTP is the
                                                                                                 transport protocol.

Table 1. Comparison of SOAP with other Distributed Architectures




Simplified Object Access Protocol (SOAP)                                                CIS 679 Management Of IS
by Inder Nandrajog                                                                                       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)           CIS 679 Management Of IS
by Inder Nandrajog                                                  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)          CIS 679 Management Of IS
by Inder Nandrajog                                                 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 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 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)            CIS 679 Management Of IS
by Inder Nandrajog                                                  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 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 SOAP message. It encapsulates the various parts of the
message and identifies it as a SOAP message.




Simplified Object Access Protocol (SOAP)           CIS 679 Management Of IS
by Inder Nandrajog                                                 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)         CIS 679 Management Of IS
by Inder Nandrajog                                               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)                 CIS 679 Management Of IS
by Inder Nandrajog                                                       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 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 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)             CIS 679 Management Of IS
by Inder Nandrajog                                                   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)               CIS 679 Management Of IS
by Inder Nandrajog                                                     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)                CIS 679 Management Of IS
by Inder Nandrajog                                                      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)           CIS 679 Management Of IS
by Inder Nandrajog                                                 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)         CIS 679 Management Of IS
by Inder Nandrajog                                               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            Hotel            Rental Car
     Web Service        Web Service        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)                 CIS 679 Management Of IS
by Inder Nandrajog                                                       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)            CIS 679 Management Of IS
by Inder Nandrajog                                                  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)         CIS 679 Management Of IS
by Inder Nandrajog                                               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)          CIS 679 Management Of IS
by Inder Nandrajog                                                Page 22

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:155
posted:11/3/2011
language:English
pages:22