I hope you guys enjoyed Developing Web Services: Part 1, in this blog we going to develop a consumer for the web service we made in Part 1. Remember in Part 1 we created two types of web methods, one accepted a simple .Net Type and the other accepts a composite or custom .Net Object type. I mentioned that simple types can be used directly by HTTP-Get and HTTP-Post and that composite web methods need to use SOAP only and therefore any consumer application calling a composite web method will need a proxy class, and this is exactly what we going to do today!
This is my own definition:
A composite web method is any web method that takes input parameters that are not Simple .Net Types
Return values of the web method will not affect the protocol you use to call them, since they always return a serialized objected, which is in XML format. So the only condition is that return values of web methods are all serializable.
One more thing, if you can keep a web methods parameters as simple types, the better! Keep that in mind. So on many occasions when developing a web service you don’t need to write a custom class for the input parameters, unless absolutely necessary. I always write custom response objects, since in them I imbed my error messages and other information that a consumer can use for decision making and exception handling.
For the BizTalk geeks, this is especially true for soap send ports to call a web service, if they use simple types, then there is no need to create a BizTalk proxy class.
I include to screen shots below of a BizTalk SOAP send port, consuming a composite web method without the use of a Orchestration.
In part 3 of this blog article, I will discuss consuming web services from BizTalk.
Ok enough chit chat, lets get moving.
If you remember from part 1, this is the steps we going to take to develop a consumer application for the Audit Web Service.
- UI (Display the results of the web service response.
- Generate web proxy reference
- Call the web service
- Capture the response
We going to write a simple windows based application that calls the web service and displays the result. We will call the AuditComplex web method.
I assume the web method we developed in part 1 is deployed to IIS. If you did not deploy it as a web service to IIS, follow these steps.
- Ensure IIS is installed on your machine
- Ensure iis_regaspnet has been run, so that IIS uses the ASP.Net engine
- Open the Solution file
- Right click the project Romiko.Audit.WebServices and select properties
- Click the web link.
- Once you are in here you can then click use IIS Web server
- Click the button ‘Create Virtual Directory’
- Close the project properties
- Check in IIS if a virtual directory is created and check it is associated with Asp.NET 2.0
- Test the web service by browsing to it.
Now when we build the web service it will work from IIS. The URL above is the URL the consuming application will use.
Application Pools for Servers (Optional)
Before we get moving, you remember in my last article in Part 1, I chatted about Application Pools, we this is where you can use them, I like my web services to run under a service account which is restricted, then I never have user name and passwords in the web.config (I hate that!). What you do is create a Application Pool and set it to run under the service account, give the service account access to the SQL database etc. Lets do this now!
Warning: This is for Windows Servers! Due to IIS on servers supporting application pools
- Create IIS app pool for our web service
- Give the application pool a name
- Go to the properties of the application pool and click identity
- Notice that the pool will run under network service, this is where you can choose a Domain Service Account.
- I created one in my test domain
- All I do is use this for the identity of the application pool
- Another nice with application pools is recycling the memory used, since the web service will be isolated from other application processes. So you can recycle it to release memory.
- In this case, at 4 am I recycle the memory
- Now we give the service account access to the database and WSS_WPG group
- And in SQL
- The last part is then to point the virtual directory used by the web service to the new application pool!
This is the nice way to do it. What you can do as well is give the WSS_WPG group access to
- Also to to the framework temp folder, C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
- If you did something wrong, like type the incorrect password for the identity, then when you browse the web service, you will get this error:
- So ensure all the steps are correct and ensure the application pool is started and the account is in the WSS_WOG group.
This security model solves all problems with permissions running ASP.NET and I hope you use it in production! NO USER NAMES AND PASSWORDS in the web.config
Ok we diverted a bit here, lets get moving, but at least we now have a clean web.config, this makes deployments much easier.
Creating the solution for the consumer
First thing we going to do is create the client project. I have decided to go for a typical Win32 application.
First, we going to design the interface, based on the inputs.
The next step is to add a web reference to the project. Visual Studio will then generate the PROXY class for you, which you can then interface with.
You can then choose a web service. I chose the one running on my local machine.
Give the Web reference a name. Mine is AuditWS. Then click Add Reference.
Click show all files.
Then you can browse the files that the reference created, we will not alter them, however, keep in mind if you ever deploy a new version of the web service, then the proxy class may need to be updated, which is easy, just right click the reference and click update.
Reference.cs contains the proxy class.
Notice that the proxy class has the default URL, in reality we will store the URL is the app.config for this application. Also, you probably have different URL’s for different environments.
Now we need to write two methods, the one method calls the simple web method and the other will call the composite web method, both web methods do the exact same thing, the only difference is the simple supports http/soap posts where is the composite supports only soap.
We will keep this consumer simple with no BOL or DAL layers, in this case the DAL layer would have been the web service reference, up to if you need this for complex consumer apps.
So the first thing is we add the following directive.
Then we can access the request and response objects.
Note: I added a ForexPurchase class to the project, so that the consuming application can emulate serializing a Forex object and auditing the object in the database for us.
ws.Url = url;
private AuditRequest BuildRequest()
Lets run it and see what happens! Set the project as the startup project and run in debug mode:
I get the following response when using simple:
I get the following response when using composite:
This is a great test, we can see the error handling is being returned in the response object, now let us resolve the Database Access problems and then run it again. I think the problem is the application pool, it is using the incorrect identity, so i will fix that quickly.
Now, we run it again.
Well, that wraps up consuming applications. In order for it to support connecting to other URL’s, add the following to the app.config:
I hope you enjoyed this article. In the next article I will discuss consuming web services from a Microsoft BizTalk Soap Send Port.