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

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.

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

Table 1. Comparison of SOAP with other Distributed Architectures

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.  

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 

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

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. 

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.  

 Listing 1 A SOAP Envelope

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.

Listing 2 Request message generated by a SOAP call

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. 

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

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 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 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/cv1199/cv1199.asp

Brown, Kent, “SOAP for Platform-Neutral Interoperability”, XML Magazine, Fall 2000,
URL: http://www.xmlmag.com/upload/free/features/xml/2000/04fal00/kb0004/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

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/dm0400/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/ys0010/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