Use of Proxy when using WebSerices

The article shows the advantages of using Proxy layer to add Web Services compared to using the "Add Web Reference" wizard.

Introduction:

Web services are commonly used in applications varying from small scale to large scale applications. In any multi-tier application it's very common for the business layer to speak to web services, and a common way to do it is using the wizard to add a web service in Visual Studio (VS) 2003/2005. The current article shows the disadvantages of using the wizard in VS 2005 and an alternate way of attaining the same effect via a proxy layer.

Adding a web service reference using Visual studio

The example shows an N tier application which uses a UI layer, a Business Service layer, Business Layer, and a Data Access Layer. The business classes communicate with the business service layer for various types of data served by enterprise wide services in a SOA.

Simple data retrieval is shown from the service layer to the UI layer accessed through the business class. The data access layer is just a template which has no functionality and is there for completeness. We have the following hierarchy in our solution:

1. Presentation Tier: UI
2. Business Layer: BusinessLayer
3. Business Service: BusinessService
4. Data Access Layer: DataAccessLayer

Adding Web Reference through Wizard!

Using visual studio, we can add a reference to a web service simply by using the wizard as shown in the steps below.

a) Add a Web Reference

b) Choose the location of the Service

 

c) SelectBusinessService

d) Add the Reference

The Problem!

Following the steps, the web reference can be added to the class and the 'Customer Name' can be returned to the UI layer from within the BusinessClass via the service. This approach would work but inherently has the following issues:

1) Every time the location of the web service is changed during development, the web service reference needs to be updated from within visual studio.

 

2) This application would have to be deployed in Dev, QA, Stage, and Prod environments and in each case, the web service is located at a different location. Since the location information is located deeply within the Business Layer dll, it's not easy to change it across environments. The only solution is to change the web reference within the business layer class, rebuild the dll and redeploy in respective environments.

See that the Web Reference location is embedded in the App.Config. This app.config file will be compiled into a dll and is not available on the webserver to be changed manually by the Admin or via an auto build process (CruiseControl.NET can be used to change the settings in automated builds). The app.config content is shown here.

The Solution!

It would be ideal to have the location of the WebService configurable. Depending on the environment, the location can be changed in the web.config and there would no environment specific data in the code. This can be easily attained by the proxy approach.

We see that the web service is running on the Cassini web server at http://localhost:2699/BusinessService/CustomerSvc.asmx.(Note that the port number in your machine can be different from the one above. You may have to make this change in the app.config and web.config files to see the example working.)

We can derive the proxy of this service by using the WSDL command utility. Open the Visual Studio 2005 Command Window utility by going to Start->Programs->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt

Type the following command in the window

Change your folder location in the command prompt to the desired destination location and type the following command.

WSDL http://localhost:2699/BusinessService/CustomerSvc.asmx?WSDL

You will notice that a proxy has been created named tool generated CustomerSvc.cs in the chosen destination folder. When you open the file, you will this constructor

public CustomerSvc()
{
       this.Url = http://localhost:2699/BusinessService/CustomerSvc.asmx;
}

Overload the constructor by passing the Url value as a parameter. The modified constructor is as follows.

public CustomerSvc(string url)
{
       this.Url = url;
}

At this point the dependence on the Url location has been eliminated and the value can be passed from the UI as a parameter. The value in the UI can be retrieved from the web.config file. The code with the change is included in the example code folder.

Easily configurable Service Url with Proxy

The Url is added as a appSetting parameter in the web.config file of the UI project.

<appSettings>

    <add  key="Url" value="http://localhost:2699/BusinessService/CustomerSvc.asmx"/>
</appSettings

The calling page Default.aspx uses this Url parameter to call the overloaded constructor of customer class in Business Layer.

Notice that with the proxy, there is no need to have the Web Service reference in Business Layer and its present just for showing both the approaches in Default.aspx. To use the code, try both the code blocks in the page Default.aspx and get an understanding of how making the proxy gives you the flexibility of changing the Web Service Url by making a simple change in the Web.Config file.

Conclusion

When the code is moved between different environments or the web service Url is changed in anyone environment, the change is easily accommodated by updating the Url key in the web.config appSettings section. This makes the site more manageable without coupling.