Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

W O R K S H O P

SOAPing Up Web Services

October 10, 2002
By Don MacVittie

>> continued from previous page

The Request/Reply Spec

	Issue TOC
	Print full article
	Print this page
	Download as PDF
	E-Mail this URL
	Flame the author

	In this article
	Introduction
	Architecturally Speaking
	The Request/Reply Spec

As we touched upon earlier, SOAP is used to send a message to a Web service and get a response. It employs XML to provide the layer of system independence Web services hope to achieve, defining a way to express URLs and parameters that can be mapped into system-dependent variables by both the caller and the service.

The header for a SOAP message bound to HTTP looks just like any other HTTP post header with a content-type of text/XML. The body of the post message holds the "SOAP Envelope," which contains the request to the service. This consists of an optional header, any name spaces to use, and the actual call with parameters, all in plain-text XML. The response is set up exactly the same way, but the results of the service with your parameters are the contents of the message (see "Example of Client SOAP Message Over HTTP" below).

Note how the (simplified) example is structured. The normal HTTP headers are present, followed by the SOAP Envelope version, the SOAP Encoding Style and the SOAP body--our area of interest. Our Web Service has an entry point defined at www.Someplace.org/GetSomeValues. This entry point takes a single string as input--we sent "test input" as the string with the XML tag paramOne.

The server processes the request and sends the following response shown in "Example of Server Response." Note again the normal HTTP header. For a "200 OK" message, the content length--if present--must be exact according to the SOAP spec. This is in line with HTTP 1.1 standards but could cause problems on some HTTP 1.0 servers. The normal content type header says "text/XML," the SOAP header includes encoding information for both the message and the header, and the SOAP body is where the "payload" is. The routine is "getSomeValueResponse," and the ResponseText is in the "Result" tag.

Web Links

• "W3C, Oasis Look for Common Web Services Ground" (InternetWeek Aug. 28, 2002)

• "Securing Web Services" (TechWeb)

• "Wash Away Those Web Service Testing Blues With Parasoft's SOAPtest" (Network Computing, June 24, 2002)

SOAP also defines the system-independent data types allowed for communications in the Web services world and provides a simple mechanism for building abstract data types out of them.

Putting It All Together

you have a working application and the WSDL file that describes its interface. What else do you need? For starters, you need to deploy the application and publish your WSDL file. Given that you are in an all .Net environment, Microsoft makes this task trivial--assuming you accept all the defaults. While a Tomcat/Apache installation requires more work, at this stage in the Web services standard, we feel more work is good. If you know how the pieces interoperate, you will understand the system better and can more easily debug it.

When the time comes to implement Web services, you need to know how to deploy them and how to build clients that use them. For most, it will be enough to understand what the request and reply packets are and how to read the main portions of WSDL files.

Don MacVittie is an applied technologist at WPS Resources. Write to him at dmacvittie@nwc.com.