SOAP
• The original idea behind web services was to provide a standard XML protocol to allow method
invocations from one system to another using HTTP.
- This idea was simple in nature, and held the promise of allowing Java and Microsoft based systems
(and any other) to communicate.
- Web Service proposed a simple standard message protocol (SOAP) to pass XML over HTTP to invoke
methods.
- Many companies were (and continue to) using simple HTTP requests that pass XML and receive and
interpret XML in return.
- SOAP provided a simple standard way to pass a method invocation through a web server.
• Out of these ideas came the Web Services cornerstone specification SOAP.
- The W3C (World Wide Web Consortium) is managing the SOAP specification.
- SOAP provides a lightweight definition of how to call procedures.
- SOAP was originally an acronym for Simple Object Access Protocol, but that acronym is no longer
relevant. It limits SOAP too much.
- The W3C now refers to SOAP as “XML Protocol”, but it still is generally referred to as SOAP.
• SOAP is a standard that defines how to send messages using XML.
- Messages can be just informational messaging.
- Messages can also represent requests for some service.
- Messages can represent a direct method call with a required response.
• We will expand on the example we used to introduce the Web Service idea.
- Recall that a Stock Price Quote service was introduced.
- The StockPriceQuote was passed a symbol and returned a number (double).
• From the client’s perspective the call to the stock quote looks like this.
StockQuoteService stockQuote = //???
double quote = stockQuote.getLastTradePrice(“LRT”);
• The client is simply passing in a string with the stock symbol in it.
- The code to invoke this message is simple, but the message sent by the client looks like the below.
POST /stockQuote HTTP/1.1
Host: www.intertechtraining.com
Content-Type: text/xml
Content-Length: 500
SOAPAction: “GetLastTradePrice”
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePrice xmlns:m="myURI">
<symbol>LRT</symbol>
</m:getLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
• Depending on what technology is used to create the Web Service one of many things could happen
when this request is received.
- A Java Servlet™ might run.
- An XSLT may run against the request.
- An ASP.Net or JSP may be processed.
- A CGI program may run.
• How you implement the service will depend on which platform is chosen.
• After the server processes the request, a response would be sent something like the following:
HTTP/1.1 200 OK
Connection: close
Content-Type: text/xml
Content-Length: 343
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePriceResponse xmlns:m="myURI">
<price>35.3</price>
</m:getLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
• So what is the SOAP of this example?
- The message being sent into the server and out of the server is wrapped with SOAP.
- SOAP defines the basic payload of the message being sent.
- You are required to include a SOAP Envelope element and in the SOAP Envelope you will find a SOAP
Body tag.
- In the SOAP Body tag the true message being sent is found.
• A major design goal for SOAP is simplicity and extensibility. There are many features common to
other distributed object systems that are not part of the core SOAP specification.
- Distributed garbage collection is missing.
- There is no “boxcarring” or batching of messages.
- No use of objects-by-reference.
- No object activation.
• This means that SOAP was not designed to be a full and robust distributed object architecture.
• Instead it has interoperability across heterogeneous platforms and languages.
• The original idea behind web services was to provide a standard XML protocol to allow method
invocations from one system to another using HTTP.
- This idea was simple in nature, and held the promise of allowing Java and Microsoft based systems
(and any other) to communicate.
- Web Service proposed a simple standard message protocol (SOAP) to pass XML over HTTP to invoke
methods.
- Many companies were (and continue to) using simple HTTP requests that pass XML and receive and
interpret XML in return.
- SOAP provided a simple standard way to pass a method invocation through a web server.
• Out of these ideas came the Web Services cornerstone specification SOAP.
- The W3C (World Wide Web Consortium) is managing the SOAP specification.
- SOAP provides a lightweight definition of how to call procedures.
- SOAP was originally an acronym for Simple Object Access Protocol, but that acronym is no longer
relevant. It limits SOAP too much.
- The W3C now refers to SOAP as “XML Protocol”, but it still is generally referred to as SOAP.
• SOAP is a standard that defines how to send messages using XML.
- Messages can be just informational messaging.
- Messages can also represent requests for some service.
- Messages can represent a direct method call with a required response.
• We will expand on the example we used to introduce the Web Service idea.
- Recall that a Stock Price Quote service was introduced.
- The StockPriceQuote was passed a symbol and returned a number (double).
• From the client’s perspective the call to the stock quote looks like this.
StockQuoteService stockQuote = //???
double quote = stockQuote.getLastTradePrice(“LRT”);
• The client is simply passing in a string with the stock symbol in it.
- The code to invoke this message is simple, but the message sent by the client looks like the below.
POST /stockQuote HTTP/1.1
Host: www.intertechtraining.com
Content-Type: text/xml
Content-Length: 500
SOAPAction: “GetLastTradePrice”
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePrice xmlns:m="myURI">
<symbol>LRT</symbol>
</m:getLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
• Depending on what technology is used to create the Web Service one of many things could happen
when this request is received.
- A Java Servlet™ might run.
- An XSLT may run against the request.
- An ASP.Net or JSP may be processed.
- A CGI program may run.
• How you implement the service will depend on which platform is chosen.
• After the server processes the request, a response would be sent something like the following:
HTTP/1.1 200 OK
Connection: close
Content-Type: text/xml
Content-Length: 343
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:getLastTradePriceResponse xmlns:m="myURI">
<price>35.3</price>
</m:getLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
• So what is the SOAP of this example?
- The message being sent into the server and out of the server is wrapped with SOAP.
- SOAP defines the basic payload of the message being sent.
- You are required to include a SOAP Envelope element and in the SOAP Envelope you will find a SOAP
Body tag.
- In the SOAP Body tag the true message being sent is found.
• A major design goal for SOAP is simplicity and extensibility. There are many features common to
other distributed object systems that are not part of the core SOAP specification.
- Distributed garbage collection is missing.
- There is no “boxcarring” or batching of messages.
- No use of objects-by-reference.
- No object activation.
• This means that SOAP was not designed to be a full and robust distributed object architecture.
• Instead it has interoperability across heterogeneous platforms and languages.
SOAP
Table of Contents
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services