Windows NT Explorer: Simple Object Access Protocol (SOAP)

Previous Windows NT Explorer articles featured in Ariadne have looked at some of the essentials tools and technologies for web development on the Microsoft Windows platform, namely Internet Information Server [1] and Active Server Pages [2]. The focus this issue is the Simple Object Access Protocol (SOAP). The protocol is a core technology in the provision of web services across the Internet. While SOAP is not a Microsoft specific technology, the protocol is being embraced by the company as it focuses effort on the provision of web services. Indeed, web developers who create solutions on the Windows platform are going to be hearing a lot about web services. Microsoft’s initiatives such as .NET [3] and HailStorm [4] are helping to transform it from a software development company to a services company. Additionally, the latest release of their development environment, Visual Studio.NET, allows developers to create and use web services in their own applications.

What is SOAP?

SOAP is a means by which distributed software applications can communicate using the open standards of HTTP and XML. The protocol was developed by a consortium of industry experts, including those from Microsoft, IBM, IONA, Ariba, DevelopMentor and others [5]. The XML format used by SOAP to describe web services is termed the Web Services Description Language (WSDL). During May 2000, the SOAP 1.1 specification [6] was submitted to the W3C consortium.

Distributed computing has been possible on Windows based systems for a while now, using an extension to COM, called the Distributed Component Object Model (DCOM), or COM+ as it is referred to in Windows 2000. Using DCOM, it is possible to install objects on one server that are able to call objects on other servers. In a multi-tier architecture model it would therefore be possible to place the user, business and data objects on separate servers. The downside to using DCOM is that unless you have very large budgets, it is essentially a Microsoft Windows-based solution. Furthermore, there are practical problems in using DCOM through firewalls, and there is a high network connectivity overhead. It is also not really a suitable technology for use over the Internet.

Because SOAP has been built on the existing protocols of XML and HTTP, it is particularly suitable for building distributed applications that use multiple servers running different operating systems and/or development environments. In this respect it offers far greater flexibility to DCOM. Microsoft have already embraced SOAP, but as is described later, a number of other platforms and development environments also support SOAP.

Using SOAP on Windows

SOAP will be an integral technology in Microsoft’s .NET platform for web services [3]. Until .NET and its associated development tools are officially released, Microsoft have made available the SOAP Toolkit [7]. This toolkit adds support for SOAP to the Internet Information Server web server on Windows NT (Internet Information Services on Windows 2000) and the Visual Studio 6 development environment. It is particularly useful for allowing COM objects to be used from remote servers in much the same way as DCOM. Another valuable reason for using the toolkit is that it hides much of the complexity of WSDL files, as well as producing and interpreting the XML data necessary to invoke and return output from web services.

The SOAP Toolkit

The SOAP Toolkit contains a number of items, many of which will be described in further detail. The WSDL/WSML Generator is a Wizard-like utility for generating the required WSDL XML files for exposing COM methods through SOAP. An ISAPI filter (or alternatively an ASP page) allows requests for .WSDL files to call the appropriate DLL on the server. Several COM objects provide a high level interface to SOAP, which allow the developer to use SOAP without having to directly program either HTTP or XML parsing routines.

The toolkit’s tracer utility is used for intercepting SOAP calls during debugging. There are also a number of sample files (mostly for Visual Basic and Visual C++), and some high quality documentation, including a complete, searchable SOAP reference guide.

Figure 1. The SOAP Toolkit contains extensive documentation in HTML Help format

Exposing COM methods through SOAP by use of the WSDL/WSML Generator

Generating the required XML for exposing SOAP services can be time consuming. Thankfully, the SOAP Toolkit has a WSDL/WSML Generator that can help generate the XML from registered COM DLLs.

The use of the Generator can be illustrated by using it to expose methods in an example COM object. The example object called NorthWind.dll, was developed using Visual J++ 6.0. The object contains code for connecting to the NorthWind Microsoft Access database via ODBC (this database is the sample database supplied with Microsoft Access). There are two methods within the COM object: getProducts and getProductDetails. getProducts returns a list of all of the data in the Products table of the NorthWind database. The getProductDetails method takes a parameter of a ProductID, and returns details of that individual product.

In the example screenshot below, the WSDL/WSML Generator is being used to expose the getProducts and getProductDetails methods in the DLL:

Figure 2. Using the SOAP Toolkit’s WSDL/WSML Generator to expose methods in a COM DLL

Note that the Wizard allows you to specify which of the methods you want to make expose through SOAP.

Once the .WSDL and .WSML files have been generated, they are placed in a publicly accessible web folder. The SOAP client can then be pointed to these files in order to access the methods exposed by SOAP.

Support for SOAP in web servers

The XML files generated by the WSDL/WSML Generator describe the methods that can be accessed through SOAP. Once these files have been uploaded to the web server, the server needs to know how to interpret requests for these documents.

SOAP calls are made by the client machine using HTTP POST to send the XML required to call a method on the web server. The web server then needs to know how to interpret this request and send back the result (which is returned in XML format).

The SOAP Toolkit supports two types of “SOAP Listeners”. The first type of listener is an ISAPI filter for IIS that allows the web server to forward requests for .WSDL files to the filter. The filter then calls the appropriate COM object and returns the result as XML. The SOAP Toolkit also supports an ASP SOAP listener. This is useful when you aren’t an administrator on the server so can’t install the ISAPI filter.

Calling SOAP methods from within Active Server Pages

Calling a SOAP method on a remote server is a process of sending and retrieving XML via HTTP. Although it is possible to directly use HTTP protocol and XML parsing routines, the SOAP Toolkit contains a number of COM objects that provide high level programmatic access to SOAP, hiding some of the complexities behind SOAP. Of particular value is the SoapClient object, which allows a SOAP method to be called and the method’s output to be returned. The object’s use is demonstrated in the sample ASP code below, which calls the getProductDetails method and displays the output from this method:

<% On Error Resume Next Dim oSoapClient Dim sProducts ‘Creates an instance of the SoapClient object Set oSoapClient = CreateObject(“MSSOAP.SoapClient”) ‘Initialises the SoapClient object by pointing it to the ‘Web Services Description Language file describing ‘the object that contains the method to be called Call oSoapClient.mssoapinit(“http://127.0.0.1/SOAPServer/NorthWind.WSDL", “NorthWind”, “”) ‘Call the getProducts method of this web service sProducts = oSoapClient.getProducts() ‘The SoapClient returns full details of any errors encountered while accessing the method If Err <> 0 Then Response.Write(“Error Description =” & Err.Description & “<br>”) Response.Write(“FaultCode =” & oSoapClient.faultcode & “<br>”) Response.Write(“FaultString =” & oSoapClient.faultstring & “<br>”) Response.Write(“FaultActor =” & oSoapClient.faultactor & “<br>”) Response.Write(“FaultDetail =” & oSoapClient.detail & “<br>”) Else ‘No errors, so display the list of products returned by the method Response.Write(”<pre>” & sProducts & “</pre>”) End If ‘Release SoapClient object Set oSoapClient = nothing %>

The SoapClient object contains some error handling functionality. Further debugging is made easier when use is made of the SOAP Trace Utility that is also a part of the SOAP Toolkit.

The code shown above can be contrasted with the code for calling the getProducts method using DCOM, where the method is in a COM object installed on a server called ComponentServer:

<% On Error Resume Next Dim oNorthWind Dim sProducts Set oNorthWind = Server.CreateObject(“NorthWind.NorthWind”, “ComponentServer”) sProducts = oNorthWind.getProducts() If Err <> 0 Then Response.Write(“Error Description =” & Err.Description & “<br>”) Else Response.Write(”<pre>” & sProducts & “</pre>”) End If Set oNorthWind = nothing %>

As can be seen from these code samples, invoking remote methods via SOAP is fairly straightforward. Being non-platform specific does have a few drawbacks though, most notably in the fact that it is not that straightforward to send and retrieve complex data types. Workarounds are possible; it is, for example, possible to send and retrieve ADO Recordsets by converting them to and from XML between the SOAP client and server [21].

The SOAP Trace Utility

A useful utility included with the SOAP Toolkit is the SOAP Trace Utility. This is used to intercept and examine the XML files transmitted between the SOAP client and the server over HTTP. A screenshot is shown in Figure 3 below - this shows the result of intercepting a call to the getProductDetails method of the example DLL. The top right pane shows the XML transmitted by the SOAP client, detailing the method to be called (i.e. getProductDetails), together with a parameter of 3, which corresponds to the third product in the Products database table. The bottom right pane shows the XML transmitted back by the SOAP server. In this instance it is the details of product 3 (in this case Aniseed Syrup).

Figure 3. The SOAP Trace Utility is used to intercept the XML files transmitted between the SOAP client and server

Using SOAP with other development environments and web servers

SOAP is based on the open standards of HTTP and XML, so it can potentially be used with any development environment or programming language that supports these. In order to speed development times, a number of environments have direct support for SOAP. Support for SOAP in Microsoft development environments through the SOAP Toolkit has already been described in some detail.

The latest version of ActiveState’s ActivePerl for Windows NT [9] has built-in support for SOAP through the inclusion of the SOAP::Lite module [10] - alternative SOAP modules for Perl are available. To demonstrate the fact that SOAP can be used in a variety of development environments, the following Perl code can be used to successfully call the getProductDetails method of the sample DLL installed on the IIS server demonstrated earlier. As with the VBScript ASP code shown earlier, it displays the details of the 3rd product in the Products database table.

The recently released version 6 of Borland Delphi also offers SOAP support [8]. Curiously there appears not to be any support for SOAP within the current version of PHP 4. This is unfortunate, as PHP would be an ideal environment in which to use web services.

It is also helpful if the web server you are using supports SOAP. Support for SOAP in Microsoft’s IIS through the addition of the SOAP ISAPI filter or ASP listener has already been mentioned. The popular Apache web server also has support for SOAP through the use of Apache SOAP [11]. Products such as IBM’s WebSphere Application Server and iPlanet E-Commerce Solutions’ iPlanet Application Server also support SOAP.

SOAP in Action 1: HailStorm

Microsoft’s HailStorm [4] is a set of .NET services designed to integrate user services on the web. It builds on the Passport user authentication scheme used an increasing number of Microsoft and non-Microsoft offerings on the web [14]. HailStorm will supply common user details, address books, calendars and payment methods. These details can then (subject to user approval) be accessed by sites making use of HailStorm.

The advantages for the website developer is that by making use of the HailStorm services, things like accepting payment for a service would simply be a matter of building the appropriate SOAP and XML connectivity required to communicate with the HailStorm service.

eBay Inc. will be one of the first 3rd parties to make use of HailStorm [15] [16]. eBay’s auction services will be made available to users of Microsoft’s products. For example, users will be able to see the status of their auctions without having to log into the eBay website.

Obviously these are early days for HailStorm, and it obviously has to gain user acceptance. But it would go a long way toward solving the problem of having to remember dozens of different passwords for subscription services, and having to log onto several accounts to check all your email. It also demonstrates that Microsoft has a firm commitment to the use of SOAP in the creation of web services.

SOAP in Action 2: UDDI

The growing number of web services available has lead to the introduction of Universal Description, Discovery and Integration (UDDI) registries. These allow organisations to publish information about their web services to a publicly accessible registry, thereby allowing current potential trading partners to find out about their web services.

At the present time, both Microsoft [12] and IBM [13] allow read and write access to the UDDI Business Registry. UDDI itself is an emerging technology, but already some organisations are making use of it. For example, the airlines Continental Airlines Inc. and Scandinavian Airlines System (SAS) have web services available through UDDI that can be used to track the status of their flights. Other services that could benefit from UDDI are those that track parcels and assets across the World, weather reporting and news/financial information services.

The advantage of UDDI is that because the descriptions of the web services are publicly available, the web developer wishing to interface to the service is easily able to gain access to all the information required to integrate the service. Over the next few months UDDI will hopefully gain critical mass, with a far greater selection of web services being available.

Resources

A few online SOAP tutorials are available, such as VBXML.com’s <soap:workshop/> [17], and there are a range of articles accessible from XML.com’s SOAP tutorials section [20]. The SOAP::Lite website [10] also has a large number of links to SOAP resources.

A few books covering SOAP are also available, including Understanding SOAP: The Authoritative Solution [18], and Professional Windows DNA: Building Distributed Web Applications with VB, COM+, MSMQ, SOAP, and ASP [19].

Summary and Conclusions

SOAP is a core technology in the provision of web services, and demonstrates the value of XML in platform independent machine communication. While there is no guarantee of the success of any emerging technology, SOAP has support from a large number of high profile organisations. The inclusion of SOAP within the latest generation of software platforms and development tools ensures that developers will be well placed to take advantage of the technology.

References

1. Windows NT Explorer: Internet Information Server, Ariadne issue 21
   http://www.ariadne.ac.uk/issue21/nt-explorer/
2. Active Server Pages, Ariadne issue 20
   http://www.ariadne.ac.uk/issue20/nt/
3. .NET Defined, Microsoft website
   http://www.microsoft.com/net/whatis.asp
4. Building User-Centric Experiences - An Introduction to Microsoft HailStorm, a Microsoft white paper
   http://www.microsoft.com/net/hailstorm.asp
5. Microsoft Submits SOAP Specification to W3C, Microsoft press release
   http://www.microsoft.com/presspass/press/2000/May00/SoapW3CPR.asp
6. Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000
   http://www.w3.org/TR/SOAP/
7. Microsoft SOAP Toolkit, Microsoft Developer Network website
   http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000523
8. What’s New in Delphi 6, Borland Software Corporation website
   http://www.borland.com/delphi/del6/whatsnew.html
9. ActivePerl, ActiveState Tool Corp. website
   http://www.activestate.com/
10. SOAP::Lite, SOAP::Lite website
    http://www.soaplite.com/
11. Apache SOAP, website
    http://xml.apache.org/soap/
12. Microsoft UDDI registry, website
    http://uddi.microsoft.com/
13. IBM UDDI registry, website
    http://www-3.ibm.com/services/uddi/find
14. Microsoft Passport, website
    http://www.passport.com/
15. ‘Hailstorm’ Virtual Pressroom, Microsoft press release
    http://www.microsoft.com/PressPass/events/hailstorm/ebay.asp
16. eBay and Microsoft Announce Strategic Alliance to Expand Global Online Presence, Microsoft press release
    http://www.microsoft.com/PressPass/press/2001/Mar01/03-12ebayPR.asp
17. VBXML.com’s <soap:workshop/>, VBXML.com website
    http://www.vbxml.com/soapworkshop/
18. Understanding SOAP: The Authoritative Solution by Kennard Scribner, Mark C. Stiver, Kenn Scribner. Sams Publishing.
    http://www.amazon.com/exec/obidos/ASIN/0672319225/brettbcom
19. Professional Windows DNA: Building Distributed Web Applications with VB, COM+, MSMQ, SOAP, and ASP by Christopher Blexrud et. al., Wrox Press.
    http://www.amazon.com/exec/obidos/ASIN/1861004451/brettbcom
20. XML.com’s SOAP tutorials section, XML.com website
    http://www.xml.com/pub/rg/153
21. Returning ADO Recordsets with SOAP Messaging, Microsoft Developer Network website
    http://msdn.microsoft.com/xml/articles/soapguide_ado.asp

Author Details

Brett spent two years working in the University of Essex Computing Service, before moving to The Internet Applications Group in the Autumn of 1999, where he developed e-Business applications for a range of corporate clients and dot-com start ups. Brett is presently working as a freelance web developer, and would be interested in any development projects you might have available. Brett’s specialist areas are in the development of web applications, primarily using Microsoft technologies such as ASP, Visual Basic, and SQL Server, but also using JavaScript, PHP, Perl and SOAP! Terms of employment and rates are negotiable, and fixed price contracts are available. No job is too small! …Further details.

Article Title: “Windows NT Explorer: Simple Object Access Protocol (SOAP)”
Author: Brett Burridge
Publication Date: 02-October-2001
Publication: Ariadne Issue 29
Originating URL: http://www.ariadne.ac.uk/issue29/ntexplorer/