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:

You go to a Web page and make a data request—probably submitting some parameters.
That Web page creates a COM object that does some work—probably querying a database.
The COM object returns some data.
The Web page returns that data to the client in XML format.

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 object
dim hResult             'as boolean
dim sXML                'as string

const 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 &lt;&gt; false then
          sXML = oProxy.GetStates()
...

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

Every 60 seconds, a component scrapes the California Department of Transportation (CALTRANS) Web site for San Diego's current traffic conditions and places all data in a data warehouse.
My various Web services return the valid states, cities, exits, and speeds.
The COM components behind the Web services query the data warehouse and return an ADO record set. The Web service's ASP page converts the ADO record set to XML and sends that back as the answer.

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

If ROPE ever generates an error while calling your Web service, you have to reboot the server; ROPE can't recover.
To perform my record set-to-XML conversion, I implemented a script function by including the function in the Web service ASP page and adding a call to it in every method that returns a record set. So I have to edit the generated files.
Don't forget to wrap all returned XML in CDATA (<!\[CDATA\[ ... \]\]>) sections. Otherwise, the returned data won't be parsed, resulting in no returned data.
And of course, the site has to be running on Windows 2000 or Windows NT 4.0 Service Pack 6 (SP6).

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.Inet
Dim sPageHTML   As String
Dim sURL        As String

'*** URL to hit, along with parameters
sURL = "http://Trafficapp.InterKnowlogy.net/GetTraffic.asp?lFreewayID=1&sDirection=s"

'*** request the page
sPageHTML = 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:

You don't have an SDL file.
You have to manually validate the parameters.
You have to perform more manual error handling.
It's not SOAP.

But it also has some advantages:

You can debug your COM code (you can't when you use the SOAP method).
Optional parameters are easier to deal with; just don't send them.
It's more stable than the current ROPE DLL.
You can run the service by surfing in a Web browser.

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.

Comments

Plain text