Deploying a Web Service

Deploying a solution is a common requirement for many business applications. With Web services, the need arises when you want to make a Web service available from a different Web server than the one that you used to develop the Web service. Typically, the deployed Web service will reside on a Web server that is more widely available or can handle more users than the development Web server. This section demonstrates the deployment of the DaysTilEOM Web service to a local intranet Web server as well as to a Web site on the Internet.

Overview

Deploying a Web service entails two steps. First, you need to copy the relevant files from a folder on the development Web server to a folder on the deployed Web server or Web site. You will typically use a Web site as the target if your Web site is provided by an ISP that shares a Web server across multiple Web site owners . Second, you need a client that connects to the deployed Web service. How you specify the proxy variable for a deployed Web service varies slightly depending on whether the Web service resides on an intranet Web server or the Internet at a Web site.

Note  

When deploying a Web service to a target Web server or Web site, make sure that the target has the .NET Framework installed. A Web service will function only on a Web server with the .NET Framework installed.

Before deploying a solution, make sure your solution compiles and operates correctly. Use the Build And Browse command to verify proper performance. After verifying valid operation, compile your Web service by choosing Build, Rebuild Solution. This yields a freshly compiled solution. I recommend you deploy to Web servers running the Microsoft FrontPage 2002 Server Extensions because they are easy to use. When your target Web server has these extensions, you can invoke the Project, Copy Project command and automatically copy relevant files from your development Web server to your deployment Web server or Web site. You can even specify a new folder at the target to hold your deployed Web service.

Deploying the DaysTilEOM Web Service

To deploy to a Web server on your intranet, invoke the Project, Copy Project command. In the Destination Project Folder text box, follow the http:// prefix with the name of your target Web server and the project folder to which you want to copy your application. For example, if your destination server has the name cablat and you want to create a folder named DeployedDaysTilEOM, enter the following URL in the text box:

http://cablat/DeployedDaysTilEOM/

This process copies from the development Web server selected files necessary to run the Web service from the target Web server. It does not copy over all the files, such as the . vsdisco file. When you create a client that points at the target Web service or you already know the URL for the target Web service, discovery files are not strictly necessary in the Web service folder.

When deploying to a Web site on the Internet, the deployment process is almost the same. Replace the server name with the URL for the Internet Web site, such as http://www.databasedevelopersgroup.com . You can follow the URL with the name of any destination folder you want to use, such as DeployedDaysTilEOM.

Note  

Although you can specify a new Web server and a new folder when you deploy a Web service, the Web service name and startup file remain the same. Therefore, the deployment folder in these examples is DeployedDaysTilEOM, but the Web service name remains DaysTilEOM and the startup file is DaysTilEOM.asmx.

Invoking a Deployed Web Service

The process for invoking a deployed Web service on an intranet was described in the previous section. Essentially, this process is the same as the process for building a client on a workstation other than the one on which the Web service is deployed. See the Building a Client Application on Another Workstation section for detailed instructions on how to construct a client application on a Web service deployed to an intranet Web server.

Intranet applications have the potential to deliver significant business value by providing extra security because they can reside behind firewalls. At the same time, this advantage restricts their availability ” especially for learning purposes. For example, you cannot connect to the DaysTilEOM Web service deployed to the cablat Web server in my office. On the other hand, you can connect to the same Web service deployed to the http://www.databasedevelopersgroup.com Web site. Start with any client that you already have for the DaysTilEOM Web service, or build a new one as described in the Building a Client Application on Another Workstation section. Then, add a new Web reference to the project. Start by choosing Project, Add Web Reference. Next, type the URL for the target .asmx file in the Address text box. In the current example, this URL would appear as follows :

http://www.databasedevelopersgroup.com/DeployedDaysTilEOM/DaysTilEOM.asmx

Then, press Enter. Finish adding the Web reference by clicking the Add Reference button.

The preceding steps add a new Web reference named com.databasedevelopersgroup.www to the Web References folder in Solution Explorer for your client application. You can optionally rename the Web reference so that you have a single-part name such as mysinglepartname rather than a multi.part.name. However, no requirement to convert the name format for the Web reference exists: when you build a proxy variable for the Web reference, the variable will normally be a single-part name. You can specify a proxy variable for the Web reference with a Dim statement such as this:

 Dim wsc1 As New com.databasedevelopersgroup.www.DaysTilEOM() 

Replace any other Dim statement declaring the wsc1 proxy variable with this one. Then, your Windows client application will connect to the Web service at the http://www.databasedevelopersgroup.com Web site.

Building an Intranet-Based Client for a Web Service

Most of the Web service clients described in this chapter are Windows applications. However, having a Web application as a client gives you a distinct advantage. A Web application does not require the installation of the .NET Framework on the client computer, but a Windows application does. Therefore, using a Web client rather than a Windows client extends the reach of a Web service.

Figure 12-7 shows a Design view and an operational view of WebForm2.aspx in the WebZipCodeClient project discussed in the Building a Web Application Client for a Web Service section. The project resides on the intranet in my office. WebForm2.aspx is the second Web page added to the project. However, this Web page points at a different Web service than that initially used in the earlier discussion of the project. Webform2.aspx points at the DaysTilEOM Web service in the DeployedDaysTilEOM folder at the http://www.databasedevelopersgroup.com Web site. The Design and operational views for the Web application client generally parallel those for the Windows application. In fact, much of the code behind the form is the same. You can see the distinct design and operational similarities of Web clients and Windows clients by comparing the forms in Figure 12-7 with those in Figure 12-6.

Figure 12-7: Design and operational view of an intranet-based Web client for the DaysTilEOM Web service

The following listing shows the two event procedures in the code behind the Web page. The Page_Load event procedure merely performs initial formatting of the controls on the Web page. The Button1_Click procedure invokes the DaysTilEOM Web service and processes its return value via the wsc1 proxy variable. A Dim statement points this proxy variable at the DaysTilEOM Web service in the com.databasedevelopersgroup.www Web reference. You can manually create this Web reference as described earlier in this section. As you can see, except for the Web reference, the Button1_Click procedure for the Web client is identical to that of the Windows client.

 Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Initialize controls If Not IsPostBack Then Prompt with date format for date text box and clear userid text box TextBox1.Text = "mm/dd/yy" TextBox2.Text = "" Assign Text property values for labels Label1.Text = "Date" Label2.Text = "UserID" Label3.Text = "" End If End Sub Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Instantiate DaysTilEOM on localhost Dim wsc1 As New _ com.databasedevelopersgroup.www.DaysTilEOM() Save the return value from the DaysTilEOM Web method in the int1 variable Dim int1 As Integer = _ wsc1.DaysTilEOM(TextBox1.Text, TextBox2.Text) Process the return value from the Web method If int1 = -1 Then MsgBox("Invalid UserID ; denied access to Web Service.") Else Label3.Text = int1.ToString & " days til end of month." End If End Sub 

Building an Internet-Based Client

As mentioned, the preceding sample extends the reach of a Web service because it does not require the .NET Framework on the computer running the client. However, that sample does not extend the reach sufficiently to enable you to browse to a page on the Internet and see the Web service in action. The sample in this section does. In fact, this sample is identical to the preceding one, except that it resides on the Internet. This simple adjustment dramatically extends the reach.

I created a new Web page, WebForm1.aspx, in the WebDaysTilEOMClient project folder of the http://www.databasedevelopersgroup.com Web site. As you might have surmised, this Web page has the same design and Web reference as those in the preceding sample, except that this Web page is available on the Internet. Therefore, you can browse to it. Figure 12-8 shows the page in a browser yielding the same result as shown in Figure 12-7. The Address box in the figure shows you the URL to use for running the DaysTilEOM Web service from your browser.

Figure 12-8: An operational view of an Internet-based Web client for the DaysTilEOM Web service