Using Web Service for Legacy Data

Web Services are a tremendous way to encapsulate data access. If I think my data access layer may be hit from multiple types of clients, I create a web service to deliver the data. This ensures easy access, no matter who may want to consume the data.

One of my current clients has an existing classic ASP site. This site handles the majority of their sales traffic. It has been in place for some time, and with plenty of initiatives for new systems, they have no desire to rewrite it in .NET. In addition to classic ASP, their site contains a number of COM components for data access. So, my goal was to use .NET to develop data access that could be used by the classic ASP and COM components, but allow a transition to new technologies when it made sense.

Note first that threading can be a big issue when it comes to connecting legacy technologies to .NET. Per Microsoft, you should not have a COM component calling a .NET component directly. This is another way that the Web Service protects you.

Architecturally, Web Services also give you a great means of load balancing. My client, like any large company, had a good-sized web farm that was handling requests. By exposing the data access layer on HTTP, the server that is most able to handle the request will do so--even if it is not the server that is processing the COM component or ASP page. In other words, a server may actually hand of this request to a more idle server, and both machines have a hand in processing the web page.

As I mentioned above, Web Services are my tool of choice when it comes to providing data to a myriad of types of clients, so this is the perfect choice in this case. Next, the problem is how to make the connection between the old technologies and a web service.

Long ago, the SOAP toolkit was the way to solve this problem. But with this technology deprecated by Microsoft, it is clearly not the solution.



So when I need to connect classic ASP or COM components to a web service, I use a direct XMLHTTP request using the MSXML component. This is a very straightforward process, and setting up the configuration information is largely a matter of copying and pasting information from the .asmx page into your program.



First, you need to set up a few functions that you will use to make the call. I put the following code in a include file for classic ASP:

 strWSUrl = "http://server/webservices/MaterialRelease/service.asmx" 
 strAction = "http://tempuri.org/GetAvailableForecasts"
 strXml = _
  "<?xml version=""1.0"" encoding=""utf-8""?>" & _
  "<soap:Envelope xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope/"">" & _
  "  <soap:Body>" & _
  "    <GetAvailableForecasts xmlns=""http://tempuri.org/"">" & _
  "      <SupplierId>" & SupplierID & "</SupplierId>" & _
  "    </GetAvailableForecasts>" & _
  "  </soap:Body>" & _
  "</soap:Envelope>"

 result = PostWebService(strWSUrl, strAction, strXml)