In my May 15 column, I began a discussion of the .NET features that let you easily build Web services. I used the following definition of a Web service: "A programmable application logic accessible using standard Web protocols" (e.g., Simple Object Access Protocol—SOAP). We built a Web service that connected to a SQL Server database and returned a dataset. To review the code for that application, go to http://www.sqlmag.com/Articles/Index.cfm?ArticleID=21082 and scroll down to the sentence that begins "We then modify our file slightly."
With the exception of a minor change to that code (setting the Data Source Name—DSN—to the appropriate server, user ID, and password), the code encapsulates all the work of connecting to the database and returning a dataset. To complete this sample, we must first save the file with the extension .asmx (e.g., DataAccess.asmx) and store it on a Microsoft IIS Web server as a publicly accessible URL, which requires that the server have the .NET Framework installed. For example, if we save the file as c:\inetput\wwwroot\DataAccess.asmx, we should be able to access it as http://localhost/DataAccess.asmx. If we request the URL to DataAccess.asmx through a browser, the system returns an HTML page that describes the capabilities of the Web service.
This Web Service Help Page enumerates the Web services (e.g., GetDataSet) offered at this URL and provides a simple HTML Form for sending HTTP-GET requests to the Web service. At the top of the document is a link to the Web service's formal XML definition.
If we select the XML definition, the system provides a language- and platform-agnostic XML description of the Web service. The system automatically creates this XML definition, which is formally known as Service Description Language (SDL). Note that while SDL works for Beta 1 of the .NET Framework and tools (Visual Studio.NET), in the .NET Framework Beta 2, Web Service Description Language (WSDL) replaces SDL. Microsoft and IBM have collaborated on WSDL and submitted it to the World Wide Web Consortium (W3C). For more discussion of WSDL, see the Featured Article in the Resources section below.
The WSDL enumerates all the Web services offered, along with their parameters, return types, and supported protocols (e.g., SOAP). This definition is so complete that tools, such as Visual Studio.NET, can use this XML file to generate a proxy class automatically. We can then use this proxy class to program the Web service in a friendly object-oriented (OO) manner.
We can also use the HTML Form that the Web service Help Page provides to test the Web service. We use the HTTP-GET protocol to send requests through the HTML Form; that is, the request is sent as http://\[path\]/DataAccess.asmx/GetDataSet?—all parameters are passed on the query string. The system returns an XML document that includes an XML schema that describes the data and the XML data conforming to that schema. In our case, the XML data is the data extracted from our database. Below is a snippet of this XML:
<products> <ProductName>City Milk</ProductName> <ProductDescription>City Milk Description</ProductDescription> <UnitPrice>2</UnitPrice> </products>
Those of you familiar with SOAP will immediately notice that this response isn't SOAP. However, the system will use SOAP when we use Visual Studio.NET (or a command-line tool) to create a proxy class from the SDL.
This sample isn't complete yet because we haven't discussed using the Web service from an application. The .NET Framework Beta 2 is so close (Microsoft has announced that attendees at TechEd 2001—June 17 through June 21 in Atlanta—will receive the Beta 2 versions of Visual Studio.NET and the .NET Framework) that we'll temporarily shelve that discussion. In my next column, we'll look at the changes from Beta 1 to Beta 2 at a macro level, discussing only the bigger changes. Then, in the column following that one, we'll come back to this Web services discussion and briefly revisit the Web Service Help Page. We'll then use the GetDataSet Web service from a Visual Studio.NET application.