Browse DevX
Sign up for e-mail newsletters from DevX


Synchronize Your Databases with .NET Web Services (Part I) : Page 6

The ever-increasing use of XML is an exciting development in Web site design and construction, and provides new ways for site authors to expose information to visitors. In this two-part article, you'll see how to create a data-driven Web service and explore three different ways to consume it. Then, in part II, you'll see how to use such services to synchronize the content in distributed databases automatically.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Consuming Web Services
While the previous sections have blithely mentioned sending SOAP or HTTP requests to the server, how do you actually accomplish that task? Sending an HTTP request is easy—the client just has to send an HTTP GET or POST request to the Web service, specifying the method they want to execute and any parameters that method requires. The example Web service shown above takes no parameters, so a request looks like this:


When the Web service method does require parameters, you add them to the URL as a query string for GET requests, or place them into the body of a <form> for a POST request. For example, if the LanguageSummary method required parameters named Year and Week, a suitable GET request would be:


Alternatively, you could use an HTML page containing the following <form> section to create a suitable POST request:

<html> <body> <form method="post" action="/traffic/trafficdata.asmx/LanguageSummary"> Year: <input type="text" size="4" name="Year" /> Week :<input type="text" size="4" name="Week" /> <input type="submit" value="Go" /> </form> </body> </html>

Author's Note: You can use the two pages get-request.htm and post-request.htm in the simple-request folder of the examples to experiment with sending parameters to a Web service.

Sending SOAP Requests to a Web Service
Sending a SOAP request to a Web service is a little more complex, as you have to create the appropriate XML message in SOAP format. The next listing shows how you would form the request for the LanguageSummary method with the same two Year and Week parameters:

<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> <LanguageSummary xmlns="..."> <Year>2004</Year> <Week>6</Week> </LanguageSummary> </soap:Body> </soap:Envelope>

The request consists of a SOAP envelope, within which is the <soap:Body> element. This contains an element that identifies the method required, and contains an element named after each of the required parameters with the parameter values as their content.

In general, the easiest way to construct a SOAP request is through an appropriate proxy object created on the client (as shown earlier in Figure 2). There are various ways that you can create this proxy, depending on the technology you are using to build the client.

The final sections of this article demonstrate how you can consume a Web service. The Web service file named trafficparameters.asmx in the webservices folder of the examples implements a single method named TrafficSummaryFromWeekYear, which accepts parameters that define the week and year to start from when returning the data from our database. Here are examples of ways that you can make a request to this Web service and use the returned data.

Building a Web Service Proxy with WSDL.exe
WSDL is the Web services Description Language, and is used to define the interface or contract for a Web service. You can view the WSDL for a Web service by clicking the Service Description link ASP.NET places in the default service description page that is generated when you access an .asmx file directly in the browser. You need the WSDL file to create a proxy. If you are accessing an ASP.NET Web service, you can get the WSDL file from it by appending ?WSDL to the URL as a query string (unless the Web service has disabled the default service page as discussed earlier in this article).

After you obtain the WSDL file, you can use the .NET Framework tool named WSDL.exe (installed by default in the C:\Program Files\Microsoft.NET\SDK\[version]\Bin\ folder) to build a suitable proxy class for a Web service. The syntax and parameters for the tool are complex, but they're fully described in the .NET SDK (search for "wsdl.exe"). However, for most scenarios, all you need is this simple command line:

wsdl.exe /language:lang /out:class-file URL-or-path-of-WSDL-file

The default language is C#, but you can use the /language parameter to specify VB (Visual Basic .NET), JS (JScript .NET) or VJS (Visual J#). The /out parameter defines the path and name of the proxy class source file that WSDL.exe should generate, and the final parameter is the URL or physical path to the WSDL file that defines the Web service.

To make things easier, you'll find a batch file (create-proxy.bat in the create-proxy folder) in the sample code that executes WSDL.exe with the appropriate parameters for the example files. Note that the batch file specifically selects the tool installed with version 1.1 of the Framework:

Editor's Note: Enter the command lines shown in this section as single lines in a command window or batch file rather than wrapped as shown in this article. One space where each line break occurs at present.

"C:\Program Files\Microsoft.NET\SDK\v1.1\Bin\wsdl.exe" /language:VB /out:IISLogProxy.vb http://../webservices/trafficparameters.asmx?WSDL

The final step is to compile the new proxy source class file and place it into the bin folder so that you can access it from an ASP.NET page. The provided batch file does this as well, creating the compiled assembly named IISLogProxy.dll:

C:\WINNT\Microsoft.NET\Framework\v1.1.4322\vbc /out:..\bin\IISLogProxy.dll /t:library /r:System.dll, System.Web.dll, System.Data.dll, System.Xml.dll, System.Web.Services.dll IISLogProxy.vb

Using the Web Service Proxy in ASP.NET
Having created an assembly that implements a proxy for the Web service, you can easily use the proxy in any other .NET application. The following example (aspnet-proxy-client.aspx in the aspnet-client folder) uses the proxy within an ASP.NET page. The page contains a server-side <form> with two text boxes for the parameter values (the week and year number) and a "submit" button; plus an ASP.NET DataGrid control:

<form runat="server"> Starting from week: <asp:TextBox id="txtWeek" Text="4" Columns="1" runat="server" /> year: <asp:TextBox id="txtYear" Text="2004" Columns="3" runat="server" /> <asp:Button id="btnGo" Text="Go" OnClick="ShowData" runat="server" /><p /> </form> <asp:DataGrid id="dgr1" runat="server" />

The "submit" button simply executes a routine named ShowData. Because the assembly is in the bin folder of the ASP.NET application, you can reference it by importing the namespace (in this case the name of the public class within the assembly). Then, within the ShowData routine, create a new instance of the proxy class and call its methods.

The ShowData routine is listed below. The method it calls is named TrafficSummaryFromWeekYear, which takes the starting week and year as parameters. You get these values from the text boxes on the page, and bind the result—a DataSet object—to the ASP.NET DataGrid control to display the contents of the WeekSummary table:

<%@Import Namespace="IISLogsParameters" %> Sub ShowData(sender As Object, args As EventArgs) Dim oWS As New IISLogsParameters() dgr1.DataSource = oWS.TrafficSummaryFromWeekYear(txtWeek.Text, _ txtYear.Text) dgr1.DataMember = "WeekSummary" dgr1.DataBind() End Sub

Figure 5 shows the example page in use. It contains extra formatting attributes on the DataGrid to provide the results you see here, but functionally the code is as simple as we've just described.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date