Simple Object Access Protocol (SOAP) is the protocol that defines the format of standard XML messages. Because the SOAP protocol is standardized, you can use it to send messages back and forth between various systems without having to worry about system type, operating system, and so on. However, if your operating system doesn’t natively support SOAP, you need to use a SOAP client.
Windows XP makes things easier with a built-in SOAP client. I’ll give you a brief introduction to SOAP and its Web service information code, the Web Service Definition Language (WSDL), and show you how to access SOAP-enabled applications natively through Windows XP by using VB script.
SOAP message components
A SOAP message is made up of four components. These components are:
- The SOAP envelope, which must enclose the XML code defining the SOAP message.
- An optional set of rules defining the mappings between languages and XML code.
- An optional Remote Procedure Call (RPC) format defining how RPC function calls are performed in SOAP messages.
- A binding section that defines the bindings between SOAP and HTTP.
WSDL overview
SOAP allows services to be exposed in a standard way, giving developers the ability to create applications by combining services from many different sources. However, for this process to work, SOAP needs to know something about the Web service that it’s interacting with. This is where WSDL comes in. WSDL provides service-specific information, such as what the service does, what parameters the service requires, and what parameters the service returns. A block of XML code contains the WSDL information.
Implementing a SOAP client
Windows XP contains a built-in copy of the client portion of the SOAP Toolkit 2.0. This means that it’s possible to build SOAP client applications or to distribute them to Windows XP users without having to distribute the client component from the SOAP Toolkit 2.0.
There are three basic steps to building a SOAP application that uses the built-in client. The application must:
- Create a SOAP client object.
- Initialize the object that it has created.
- Call the method.
Create the client
In a VB environment, the following two lines of code would create a SOAP client:
Dim SOAPClient
Set SOAPCLient = createobject(“MSSOAP.SOAPClient”)
Initialize the client
After you’ve created the client, the next step is to initialize it. Typically, this involves associating the client with a WSDL file. The WSDL file can be either local or Web based, and you can address it by either a local file path or a URL. Using a local file path is more efficient, but typically you’d want to specify the WSDL file in URL format if the application will be Web based or will rely on widely distributed components. Here’s an example of how you’d initialize a SOAP client via a fictitious WSDL file called Bogus_Service.WSDL in a Visual Basic environment:
SOAPClient.mssoapinit(http://www/brienposey.com/sd/Bogus_Service.wsdl)
Call the method
When you’ve initialized the client, the last step is to call the method. Calling the method is similar to executing a procedure. The idea is that the client calls one of the methods or procedures defined in the WSDL file and then passes the required parameters to the method. The method then performs a calculation based on the parameters received and returns a result.
For example, suppose you were writing a program that reported NCAA basketball statistics. One of the modules in your application might be used to compute the win/loss ratio between two teams. You could call this method Winlose. This method would probably require you to pass it the name of two teams, and it would then return a numeric value for a win/loss ratio. In a VB environment, a call to such a method would look something like this:
wscript.echo SOAPClient.winlose(“Kentucky Wildcats”,”Louisville Cardinals”)
Of course, this is just sample code rather than a complete application, but the few lines of code that I’ve given could be combined into a functional VB script—some error handlers are all that’s missing. If you wanted to try running a script like this one, you would simply save the code to a VBS file and then execute the file using the CSCRIPT command. For example, if you called the VBS file Ncaa.vbs, you could execute the code by entering cscript.ncaa.vbs.
So, just what does WSDL look like?
Although a WSDL file can be overwhelming to first-time SOAP developers, the file is actually quite logical. There are several distinct sections in any WSDL file: definition element, message section, port type section, binding section, and service section.
Definition element
The first part of the file is a definition element. This section establishes all of the namespaces that will be used throughout the file. Below I’ve included a code segment to show you what this part of the file looks like, but keep in mind that this code segment is purely fictitious.
<definitions
name=”net.xmethods.services.ncaateams.NCAATeams”
targetNamespace=http://www.brienposey.com/wsdl/
net.xmethods.services.ncaateams.NCAATeams/
xmlns:tns=http://www.brienposey.com/wsdl/
net.xmethods.services.ncaateams.NCAATeams/
xmlns:electric=”http://www.brienposey.com/”
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:soapenc=”http://schemas.xmlsoap.org/soap/encoding/”
xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”
xmlns=”http://schemas.xmlsoap.org/wsdl/”>
</definitions>
In more complex WSDL files, there may be some schema declarations found in a Type section, but not all WSDL files have this.
Message section
The next section that all WSDL files have is the message section. This section defines both inbound and outbound messages handled by the file. In my sample code below, notice that the GetTeamRequest section accepts two team names and associates those names with some variables. The GetTeamResponse section exists for the purpose of passing the output back to the client that requested it.
<message name=”GetTeamRequest”>
<part name=”team1″ type=”xsd:string” />
<part name=”team2″ type=”xsd:string” />
</message>
<message name=”getTeamResponse”>
<part name=”Result” type=”xsd:float” />
</message>
Port type section
The next section is the port type section. This section defines the names of the methods or procedures that the file contains. For example, the code segment below defines a method called Winlose. Notice that this code segment references the input and output messages that I defined earlier.
<portType name=”net.xmethods.services.ncaateams.NCAATeamsPortType”>
<operation name=“winlose” parameterOrder=”team1 team2″>
<input message=”tns:GetTeamRequest” />
<output message=”tns:getTeamResponse” />
</operation>
</portType>
Binding section
Next, WSDL files typically contain a binding section similar to the one shown below. This code segment would associate the WSDL file with the HTTP protocol.
<binding name=
“net.xmethods.services.ncaateams.NCAATeamsBinding”
type=”tns:net.xmethods.services.ncaateams.NCAATeamsPortType”>
<soap:binding style=
“rpc” transport=”http://schemas.xmlsoap.org/soap/http” />
<operation name=“winlose”>
<soap:operation soapAction=”urn:xmethods-NCAATeams#getRate” />
<input>
<soap:body use=”encoded” namespace=”urn:xmethods-NCAATeams”
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” />
</input>
<output>
<soap:body use=”encoded” namespace=”urn:xmethods-NCAATeams”
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” />
</output>
</operation>
</binding>
Service section
The final component of a WSDL file is the service section. This is the section that ties the WSDL file to the actual service that’s running on the server. You can see an example of how this works below:
<service>
name=”net.xmethods.services.ncaateams.NCAATeamsService”>
<documentation>
net.xmethods.services.ncaateams.NCAATeams web service
</documentation>
<port name=”net.xmethods.services.ncaateams.NCAATeamsPort”
binding=”tns:net.xmethods.services.
ncaateams.NCAATeamsBinding”>
<soap:address location=”http://207.217.96.35:9090/soap” />
</port>
</service>