Summary: Simple Object Access Protocol (SOAP) is an XML-based protocol that defines a framework for passing messages between systems over the Internet. It's typically used for executing remote procedure calls. SOAP was originally intended and defined for use on top of HTTP to make SOAP more easily incorporated into Web-based applications, but other transport protocols, such as SMTP, can also be used.

Let's say that you're building an Internet application service; customers interact with it by submitting information. Your servers process the data and return results to the customers. What's the best way to get that data into and out of your systems?

You could build a custom client/server application and require your customers to use the client software to access your service. But if you're doing business over the Internet, you have to build the client to run on all possible client platforms -- Windows, Macintosh, Unix, Linux and more. That's a lot of clients to write.

How about using the Web? That works, but you're still tied to browser implementations, and you still have to build an infrastructure to send and receive input and output and to format and package that data for transmission. For a complicated application, you may opt for Java or ActiveX code, but then you start losing users to bandwidth and security issues.

What's needed is a simple protocol that makes it easy to package application data and send it back and forth across the Web, using the content-tagging language XML to ensure that both the sender and the recipient can easily interpret the contents of any messages. And using the Web protocol HTTP as the transport would eliminate the need for more firewall holes.

That pretty much describes Simple Object Access Protocol (SOAP) -- a simple "glue" protocol that lets nodes remotely invoke application objects and return results. SOAP provides a lowest common denominator for applications to transmit messages: A client can send a message to invoke some program object, and a server can return the results of that invocation.

SOAP is pretty simple: Messages are just XML documents that contain SOAP instructions. Though in theory, SOAP can be bound to any application transport protocol, it's commonly used with HTTP.

Kennard Scribner, co-author of Understanding SOAP: The Authoritative Solution (Macmillan USA, 2000), explains that SOAP works by converting method-invocation information such as argument data and transaction identifiers into an XML format.

The data is encapsulated into HTTP or some other transport protocol and sent to its destination, which is usually a server. That server extracts the SOAP data, does the requested processing and returns the results in a SOAP reply.

Scribner says, "SOAP acts as a remote-procedure call protocol, much like Java's Remote Method Invocation protocol or the CORBA's [Common Object Request Broker Architecture] General Inter-ORB Protocol."

Scribner says that because HTTP and XML are widely implemented, SOAP is "probably the most highly scalable [remote-procedure call] protocol yet invented." And yet, he adds, "SOAP is not designed to act as a complete object-based architecture."

SOAP doesn't replace Java's Remote Method Invocation protocol, Distributed Component Object Model and CORBA; it provides a framework for using any of those models. SOAP isn't a complete solution: It doesn't handle object activation or security. Scribner says the SOAP architects "clearly believed you would add that code yourself," layering it on top of SOAP, rather than making it a part of the protocol itself.

The illustration at left includes an example taken from the SOAP 1.1 specification, in which a host requests a stock price from a quote service. The SOAP request is embedded in an HTTP POST, and the body of the request indicates the request type and a parameter -- the stock symbol. The response is also an XML object encapsulated in an HTTP response, with a single returned value -- 34.5 in this case.

What's Special About SOAP?

With SOAP, developers can roll out Web services as quickly as they can build SOAP messages for program calls to existing applications and then embed those applications in simple Web pages. But developers can also use SOAP calls in dedicated applications, and they can build applications that can be dragged onto other people's Web pages instead of requiring time-consuming and costly development.

Mark Stiver, co-author of Understanding SOAP, says that this is exactly Microsoft's goal with Microsoft .Net. Stiver explains, "This is where SOAP really shines. It lets developers make sound choices about how they should build applications, without having to worry about incompatibilities."

A SOAP Sample

The following example illustrates a SOAP request called GetLastTradePrice, which allows the client to request the last trade price for a specified stock.

POST/StockQuote HTTP/1.1

Host: www.stockquoteserver.com

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

Content-Length: nnnn

SOAPAction: "Some-URI"

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

DIS

The first five lines, part of the HTTP header, indicate the type of message (a POST), the host, content type and length and the SOAPAction header, which gives the intent of the SOAP request. The SOAP message itself is an XML document, with the SOAP envelope first, then an XML element that specifies the SOAP name space and attributes, if any. The SOAP envelope may include a header (though not here), followed by a SOAP body. In this case, the body specifies the GetLastTradePrice request and the stock symbol for which the last trade price is requested. A response to this SOAP request might look like this:

HTTP/1.1 200 OK

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

Content-Length: nnnn

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

34.5

Again, the first three lines are part of the HTTP header; the SOAP message itself consists of an envelope that contains the response to the original request, labeled GetLastTradePriceResponse, and includes the value returned, in this case 34.5.

» posted by abennett

Computer World

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine