 | Your \Program Files\Seua11\Chaptr31\AlphaDist folder contains a duplicate of the AlphaDist.mdf MSDE 2000 database that serves as the data source for the online Alpha Web service. Attaching the database to your local SQL Server 2000 instance is easy, and so is modifying the AlphaTest.mdb or SQLXML3 consumers to run from your computer rather than the OakLeaf site. Testing the new service requires installing WSS, as described in the earlier "Exploring XML Web Services with .NET WebService Studio" section. |
Setting Up and Testing the Local Alpha Web Service Following is the drill to attach the AlphaDist to SQL Server and expose AlphaDist's four stored procedures as Web methods of a local Alpha service: Create a new Access data project using existing data named AlphaDist.mdb. On the Connection page of the DataLink Properties dialog, select (local) or your computer name as the server, select the use Windows Integrated Security option, and select the Attach a Database File as a Database Name option. In the text box under the selected option, type AlphaDist, click the Browse button, navigate to your \Program Files\Seua11\Chaptr31\AlphaDist folder and double-click AlphaDist.mdf to attach the database and close the Select SQL Server Database dialog (see Figure 31.21). Figure 31.21. These settings attach the AlphaDist.mdf sample database to your local instance of SQL Server2000 and create a new AlphaDist_log.ldf log file.  Click Test Connection to verify that attaching succeeded, dismiss the dialog, and click OK to close the DataLink Properties dialog. Open the Products table to verify that you have access to the new database as a member of the local BUILTIN\Administrators group. Open one of the GetTop### queries; each query returns a result set for all products because the stored procedures have default values for the six parameters. Close AlphaDist.adp. Note Opening the stored procedures in Query Design view doesn't display the parameter values in the SQL pane. If you open the procedures, don't save changes. Tip The following accelerated steps assume that you completed (or at least read) the earlier "Creating a Simple Web Service" section. If you didn't, review that section's steps and figures before proceeding. Create an \Inetpub\SQLXML folder for the new virtual directory, and open the IIS Virtual Directory Management for SQLXML (3.0) snap-in. Add a virtual directory named SQLXML that points to the new subfolder, specify the Use Windows Integrated authentication option on the Security page, select (local) as the server and AlphaDist as the database on the Datasource page, mark the Allow POST checkbox on the Settings page, and click the Virtual Names tab. On the Virtual Names page specify Alpha as the Name, SOAP as the type, and set the Path to \Intetpub\SQLXML. Click Save and Configure to open the SOAP Virtual Name Configuration dialog. Click the Browse button to open the SOAP Stored Procedure Mapping dialog, select GetTop10 from the list, and click OK to close the dialog. Accept the SOAP Virtual Name Configuration page's defaults, and click Save to Add the method to the Methods list. With the <New Method Mapping> item selected, repeat steps 8 and 9 for the GetTop25, GetTop50, and GetTop100 procedures. Click OK twice to close both dialogs and add the SQLXML virtual directory.
Give your new Web service a quick test with WSS by following the instructions in the earlier "Running WSS with a Public Web Service" section. In step 2, type http://computername/sqlxml/alpha?wsdl in the WSDL EndPoint text box. Alternatively, substitute localhost for your computer's NetBIOS name. Modifying the Sample Consumers to Use the Local Service Moving from the public Web service at http://www.oakleaf.ws/sqlxml/alpha to your locally hosted service is simple. The only changes you need to make to Web service consumer applications are the WSDL document location (c_WSDL_URL) and namespace (c_SERVICE_NAMESPACE) constant values in the clsws_ServiceName class's Declarations section. Caution When changing c_WSDL_URL and c_SERVICE_NAMESPACE values, make sure the new values are identical to the values you specified for the domain, virtual directory, and service name. Namespaces are case sensitive, and you receive an error message if the c_SERVICE_NAMESPACE doesn't match exactly. WSDL URLs aren't case sensitive, but it's a good practice to use identical URL and namespace values.
Follow these steps to change consuming applications' Web service providers, using the Alpha service as an example: Create a copy of AlphaTest.mdb and, optionally, SQLXML3Alpha.mdb in the same or another directory. Open the clsws_ServiceName class module, clsws_Alpha for this example, and replace all instances of the original service location (www.oakleaf.ws) with the new domain name, usually your COMPUTERNAME. OAKLEAF-XP1 is the domain name for this chapter's examples. Tip If you changed the name or capitalization of the virtual directory, Web service, or both, you must replace additional elements of the c_SERVICE_NAMESPACE and c_WSDL_URL values. Compile your code and test the application with the new service.
If you encounter an error message when attempting to consume the Web service from the new location, verify that the changes you made to c_SERVICE_NAMESPACE are identical to the targetNamespace attribute value in the second line of the service's WSDL document. Tip If you want to give other users in your Windows 2000+ domain access to your service, you must add SQL Server logins and user accounts for the database. Alternatively, you can specify Anonymous Access to the virtual directory with the built-in IUSR_COMPUTERNAME Windows guest account. In either case, you must grant the account at least sp_datareader privileges for the server or specific privileges for the database.
|
