Using SOAP to Set Up Web Access to Your Server's Registry

By the time you read this, Microsoft DevDays 2000 will have wrapped up. Those of you who attended saw how Microsoft is building its suite of .NET servers, such as BizTalk and Commerce 2000, around XML and Simple Object Access Protocol (SOAP). Given the attention and importance of these technologies to the future of Web services, let's discuss putting SOAP to work and taking advantage of this XML-based protocol with existing components. As an example, let's examine the SOAP Toolkit for Visual Studio 6.0, which is available at the Microsoft Web site.

Microsoft released the SOAP Toolkit in June and updated it in late July to meet evolving standards. Unfortunately, the name is somewhat misleading. The Toolkit isn't just a set of components for use within Visual Studio (VS); the SOAP Toolkit provides the infrastructure necessary for a server to expose SOAP-based Web services on the Windows OS. Installing these components on your Web site exposes simple interfaces that your business partners can use to reference your data across the Web. The only caveat is that your site must run on Windows 2000 to support a SOAP interface.

Among the key components of the SOAP Toolkit is listener.asp, a file that provides all the generic plumbing that your interfaces need to communicate. To enable your Web site's support of the SOAP interface, you must place listener.asp on your Web site in a location that lets the various interfaces you create access it easily. Listener.asp is then included in each interface that you create using the SOAP Wizard.

The SOAP Wizard installs when you install the SOAP Toolkit. If you look in the default installation directory, you can find the wizard directory, which contains only one item. When you start the wizard, a welcome screen appears to explain that the wizard lets you select an existing COM DLL that automatically creates the necessary Service Description Language (SDL) file. (SDL is a Microsoft-specific XML vocabulary that Microsoft plans to eventually replace with the World Wide Web Consortium—W3C—SOAP Contract Language—SCL—vocabulary.) Before you worry about using SDL files that will become obsolete, keep in mind that everything we're doing is generated. In other words, when the standard changes, you can simply regenerate the files and support the new standard.

On the wizard's next screen, you can select an existing DLL. Give it a try—pick any COM DLL that you have available, and click Next. Let's say you choose regtool5.dll, which is part of VS 6.0 Service Pack 3 (SP3) and handles registry access calls.

On the next screen, the wizard displays the available interfaces based on the type library for the object you selected. If you expand the interface, you can select from any of the method calls that make up the interface. In our example, regtool5.dll supports four possible calls. You select the methods you want to make available via a SOAP interface and proceed to the next step.

At this stage, you need to reference the listener.asp file to build your SDL. This step is important because the wizard is preparing to create the SDL file, and it needs to know where to find the listener. The fact that you can enter a server name means that you really need to place the listener in only one location. Just remember that, as with other Active Server Pages (ASP) includes, you must let users access the file with Read permissions.

That brings us to the final step—deciding where to publish your new SOAP interface. Pick the directory that your service's URL references, and the wizard creates the two files necessary to support your new Web service. Each file has a name based on the selected DLL. The first file, which has an .xml extension, is the generated SDL file. If you want to put your XML knowledge to the test, open the file and see whether it takes more than a few seconds to read all about your new interface. The second file, your interface, has an .asp extension. In our example, the file RegTool5.asp exposes your registry object.

The great thing about the steps I've described is that they don't require you to write one line of XML code. XML is just the mechanism that defines and transports this new interface. Don't let all the XML hype intimidate you—in our example, we created a complex interface definition in XML in a matter of minutes. As long as you can read and have a basic understanding of XML, you can keep up with all the changes that are occurring. XML is an eXtremely Manageable Language.