Web services are powerful tools for integrating applications because they have no user interface and are designed for programmatic access by other software. Instead of invoking a URL that represents a Web page, you invoke a URL that represents a method available on a remote object. Similarly, instead of receiving colorful and animated HTML code, you get back XML Schema data types packed in an XML message.

When you point the browser to a URL, you don’t care about the Web server platform or about the API used to build it. Likewise, you invoke a Web service method irrespective of the communicating platforms. To make it short, the Web service model is just another programming model running on top of the ubiquitous HTTP protocol.

To help you understand how .NET Web services work, I’ll share some simple examples and discuss how to invoke them through a script.

An example of a .NET Web service
In general terms, a Web service is a platform-specific component that can be driven and invoked from external code running on any other platform. It can be a Java class or a COM component.

On the .NET platform, a Web service is nothing more than a managed class with some publicly accessible methods. Explaining how to build Web services with .NET is beyond the scope of this article, so I will assume that you already have a .NET Web service up and running on your Web server.

As a demonstration, copy the code in Listing A to a new text file and save it with a .asmx extension. Then, place the file in an IIS virtual folder on a machine that runs the .NET Framework and ASP.NET. Once you’ve finished, you have just created your first .NET Web service. It’s a trivial one, indeed, but is sophisticated enough to discuss how to invoke it script-wise.

A Web service is always invoked through an ordinary HTTP packet that contains information about the method to call and the arguments to use. All this information is packed in an XML string written according to the SOAP vocabulary. SOAP is the universal XML-based language used to define a remote method invocation.

The HTTP packet that reaches the Web server typically contains a SOAP message that describes the call to execute. The HTTP packet travels over the network carried by ordinary HTTP commands, such as the GET command or, more likely, the POST command.

Invoking a Web service
By default, a .NET Web service can be invoked in three ways:

  • ·        A POST command that embeds a SOAP request
  • ·        A POST command that specifies the method name and parameters
  • ·        A GET command whose URL contains the method name and parameters

Each way denotes a different format for the content of the HTTP packet that hits the Web server. In other words—and in spite of the hype that too often accompanies the SOAP protocol—SOAP isn’t necessary to invoke a method on a Web service. You can employ the GET or POST direct commands, which also results in a more compact body. However, the fact that you could use plain HTTP commands doesn’t necessarily imply that this is the best way of invoking the Web service. Using non-SOAP messages can lead to security holes too.

The benefits of using SOAP, though, become clearer as the complexity of the data to handle increases. The GET and POST commands support primitive types, including arrays and enumerations. But SOAP relies on a portable and more complex type system based on XML schemas. In addition, .NET Web services also support all classes that the .NET XML serializer can handle.

As I mentioned, POST, GET, and SOAP are the ways of invoking a Web service that are enabled by default. In the .NET platform, an administrator can disable any of these invocation protocols at will. However, it’s rather unlikely that the SOAP protocol will ever be disabled; it’s much more likely, instead, that the HTTP POST and GET calls are prohibited. Let’s take a look at the default case and see what we need to write a simple VBScript file to invoke the sample Web service.

A VBScript example
To send out HTTP commands from script code, I’ll use the Microsoft.XmlHttp object—a native component of Microsoft Internet Explorer 5 and MSXML 3.0 and later versions. The script in Listing B calls the method GetYourTime on the Web service by using a GET command.

The resultant XML string—accessed through the responseText property—is the full XML document. The body of the root node of the XML file is the actual return value.

In Listing C, you can see how to accomplish the same using a POST command. Only a few changes are needed. In particular, you must set the Content-Type header and store the command string in the body. For GET commands, you instead append the method name and arguments to the URL.

Using script code to invoke a Web service is effective if you can’t afford more powerful types of client. It also results in a more effective data exchange because the amount of text being sent is significantly smaller than with SOAP, which is a fairly verbose protocol indeed.

SOAP eliminates the threat of malicious code because it is message-based (code running on server). On the flip side, script running in a Web page may be hacked with malicious code inserted.