Introducing SOAP

Distributed Component Object Model (DCOM), Remote Data Services (RDS), or Remote Scripting to communicate with distributed objects, thus providing no simple or efficient way for consumer or provider applications to communicate easily across the Internet through proxy servers and firewalls.

SOAP was submitted to the W3C by Microsoft, IBM, DevelopMentor, and UserLand among others to address these issues. There are two major stated goals of the SOAP specification:

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

Create an extensible protocol and payload format that can evolve over time.

SOAP eliminates a lot of the complexity associated with the other distributed object invocation solutions, such as DCOM and IIOP, by simply not specifying how issues such as garbage collection, type safety, versioning, object by reference, and other similar communication issues should be handled. Instead it focuses on simply defining the mechanism to pass commands and parameters between HTTP clients and servers regardless of the operating system, programming language, or object model used on either side of the communication.

Early product implementations of SOAP illustrate the broad diversity of object models, platforms, and programming languages. These include:

Nouveau ORB by Rogue Wave

Orbix 2000 by Iona

Voyager by ObjectSpace

Frontier Groupware by UserLand

Windows DNA by Microsoft

Accessing Remote Data with SOAP

Let’s look at an example of how the SOAP specification allows two applications to operate across firewalls to provide services to one another. We will examine a theoretical Web site, www.soapitup.com, which provides personalized portal pages for its customers. The site runs on a Sun Solaris platform using Java Servlets to support the delivery of customized stock quotes and research to its customers.

Another site, www.stockquoteserver.com, is a service that provides realtime stock quotes, volume and trade data, and other information as a B2B service. This site operates on a Windows 2000-based architecture using an ASP.NET solution to provide its service.

www.soapitup.com would like to access the GetQuote method of the StockQuote Service on the www.stockquoteserver.com site, and then return the results of the service to www.soapitup.com end users.

Prior to the SOAP application this type of communication for anything but the most simplistic of calls would have been extremely difficult and time consuming to develop as the applications are operating on two distinct object models, CORBA and COM.

With SOAP, however, this heterogeneous environment can communicate easily, allowing the Java Servlets to activate the COM objects on www.stockquoteserver.com with ease.

Figure 27-1 illustrates how a www.soapitup.com customer would access the www.soapitup.com Web site and be provided with a stock quote that was retrieved by www.soapitup.com from www.stockquoteserver.com.

1) Client visits www.soapitup.com and requests a stock quote

9) Client Receives

HTML Page with Result

HTTP + HTML HTTP + HTML

Internet

Figure 27-1 Illustration of SOAP request in heterogeneous environment

Figure 27-1 illustrates each of the steps that occur in a SOAP Communication. Lets look at each step below:

1.First, a customer opens the stockquote.jsp page on the www.soapitup.com WebWeb site. The user requests a stock quote by entering a stock name and hitting the submit button.

2.Next, the stockquote.jsp page captures the stock symbol from the user.

3.The stockquote.jsp page then invokes a client proxy for the www.stockquoteserver.com GetQuote object.

4.This proxy will generate a SOAP client request and encapsulate it in an HTTP POST as follows:

POST /StockQuote.asmx HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml; charset=”utf-8”

Content-Length: nnn

<SOAP-ENV:Envelope>

<SOAP-ENV:Body>

<m:GetQuote xmlns:m=”Some-Namespace-URI”>

<symbol>IBM</symbol>

</m:GetQuote>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The first four lines are standard HTTP, indicating a posting of the content to http://www.stockquoteserver.com/StockQuote.asmx. The content type is defined as text/xml, which lets the server know that the payload is going to be sent as an XML message.

SOAP defines two types of messages, Call and Response, in order to allow clients to invoke a remote procedure and allow the called procedure on the server to respond with appropriate values.

The Call example above defines the envelope and body in a standard XML structure that clearly indicates we are accessing the GetQuote method and passing the value IBM as the parameter.

5.Because this request is a standard HTTP POST that embeds XML, there are no issues passing this request across the firewall protecting the www.stockquoteserver.com site.

6.Once the stockquote.asmx page receives the request, it can quickly decipher the XML structure of the request and call the GetQuote method and pass the value IBM as the parameter.

7.Once the value is retrieved, a SOAP response message is created as follows:

HTTP/1.1 200 OK

Content-Type: text/xml; charset=”utf-8”

Content-Length: nnnn

<SOAP-ENV:Envelope>

<SOAP-ENV:Body>

<m:GetQuoteResponse xmlns:m=”Some-Namespace-URI”>

<result>110</result>

</m:GetQuoteResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>