Two Web Services Solutions

Web Services have become the hottest thing since COM. With Microsoft's release of its Simple Object Access Protocol (SOAP) Toolkit, it should be that much easier to create and use Web services—but is it? Web Services are based on XML, HTTP, and SOAP. But if you boil away all of the hype and fancy catch words, here's what's really going down:

In the October 3 XML UPDATE column, Rodney Guzman requested a wireless application that would let him check traffic conditions during his drive to work—a cool but practical use for a Wireless Application Protocol (WAP) application. In the October 17 XML UPDATE column, Bill Sheldon described how to use the SOAP Toolkit. I'm taking the next step, creating a series of Web services that provide all the data necessary for such a WAP traffic application to work.

The SOAP Toolkit provides a Remote Object Proxy Engine (ROPE) DLL, a wizard that creates the XML file Service Description Language (SDL) to self-describe the services you're exposing, and listener.asp, an ASP page that handles all the magic for the actual Web service requests. The ROPE DLL includes a proxy object that lets you consume (call) a Web service just like any other COM object's method:

dim oProxy              'as objectdim hResult             'as booleandim sXML                'as stringconst URI_SDL = "http...Trafficapp.InterKnowlogy.net/cTrafficApp.xml"const icURI = = 1             'Schema location type (URI based)set oProxy = server.CreateObject("ROPE.Proxy")hResult = oProxy.LoadServicesDescription(icURI,URI_SDL)if hResult <> false then          sXML = oProxy.GetStates()...

In a nutshell, here's how my Traffic App Web service works:

While working with my Web services, I discovered a few issues with ROPE and the SOAP Toolkit:

What if you're not willing to live with these issues? You can make your own Web service from scratch, as I did (see Figure 1 for the code). This manual Web service technique requires that you have an ASP page for every method (the same logic works for non-ASP sites). But you can consume the service by surfing to it. You can submit parameters by posting or even by URL values. From Visual Basic (VB), you can consume this service using the Microsoft Internet Transfer Control:

Dim objInet     As New InetCtlsObjects.InetDim sPageHTML   As StringDim sURL        As String'*** URL to hit, along with parameterssURL = "http://Trafficapp.InterKnowlogy.net/GetTraffic.asp?lFreewayID=1&sDirection=s"'*** request the pagesPageHTML = objInet.OpenURL(sURL)Set objInet = Nothing'*** manipulate XML Document...

To make up for my lack of an SDL, I return usage instructions for the method if no parameters are sent in (remember DOS?).

This approach has some drawbacks:

But it also has some advantages:

This solution is more viable when the Web service consumer has a closer relationship with the Web Service Provider and you want to expose a Web service now and don't want to wait for the stable release of ROPE and more SOAP components.

So am I telling you to drop the SOAP? By no means. SOAP is the common standard that we need. I'm simply suggesting that you wait for ROPE to stabilize. If you ask me, it's still a beta of sorts. That's why Microsoft called it the SOAP Toolkit and not the Visual Studio.NET SOAP Web Service.

Click here for the SDL file to start using the Traffic App Web services I generated using the SOAP Toolkit. They are live and being updated every minute. NOTE: Be sure to use the returned values FROM the Web services as the valid parameters FOR the Web services. Then click here for my homemade Web service that will also return the traffic speeds.