You may recall from Part 1 that SOAP procedure calls are formatted as XML, as indicated by the following code listings:
Message: <?xml version='1.0'?> <SOAP:Envelope xmlns:SOAP='urn:schemas-xmlsoap-org:soap.v1'> <SOAP:Body> <i:getUserAddress xmlns:i='someInterface'> <userID>198172</userID> </i:getUserAddress> </SOAP:Body> </SOAP:Envelope> Response: <SOAP:Envelope xmlns:SOAP='urn:schemas-xmlsoap-org:soap.v1'> <SOAP:Body> <i:fResponse xmlns:i='someInterface'> <address>123 N. Elm Street Fargo, North Dakota </address> </i:fResponse> </SOAP:Body> </SOAP:Envelope>
At a high level, sending and receiving SOAP calls works just like any RPC mechanism. Software applications typically complete the following steps to make use of one or more code procedures:
Declare a code library to be used (either through an include or import statement or through the use of something like Visual Basic's References menu).
Declare and populate all variables to be passed to the function.
Call the function.
"Catch" and process the function's return values.
Note that when using "traditional" tools, you needed library documentation so that you knew which functions were available and what parameters they accepted. As I'll show in just a moment, a new language named WDSL, proposed by Microsoft and IBM ( http://news.cnet.com/news/0-1003-200-2863465.html), allows web services to provide this functional description through the use of formatted XML.
While it's certainly possible to build a SOAP application using nothing but your favorite programming language and an XML parser, you'll save a great deal of time and effort by making use of a SOAP API that encapsulates SOAP functionality within a structured API. In this article, I'll examine the Apache SOAP Java API (see http://xml.apache.org/soap/index.html) and will also briefly touch on the Microsoft SOAP Toolkit.