Peter's Gekko

public Blog MyNotepad : Imho { }

Add a web service to an existing web project (?)

Here's the problem : We have quite a website which works with quite a database. The end user can only reach the web-server, the web server itself is the only one who can connect to the database. All works well but there is an extra feature which has to pump and check bulk data into the database from a COM server. The COM server itself has the tendency to pop up occasional dialogs so it just has to run on a manned workstation. (Imagine a web server popping up a dialog. It will have to wait until someone will visit the server room and take a look at that particular screen. Could take weeks) A good way for the client side app to communicate with the database is a web service. The server-side code of the web service implementation can reach the database. The client side sends and receives XML datasets to and from the web service.

There are several ways to implement an asmx web service with Visual Studio

Listen carefully to the story Christian Weyer has to tell and use his Contract First tool
Create a new project and pick new web service
Add a web service to the existing web site project. Right click the project and just pick it:

The latter works like a snap. After all a web service is not that much different from a web page. Both a a matter of request and response. In the case of a web page a bunch of HTML is returned, in the case of a web service a bunch of XML is returned. When you browse through the classes in the .NET framework which are used you will see great overlap. Both a web service project and a web site project are based on the System.Web.HttpApplication class (in global.asax)

Implementing a service this way has some big pro's

It's deployed with the site itself. No extra steps needed. Simple setup.
It uses the same web.config. No extra configuration required.

It could have some con's as well...

Dave's first point, rolling out on one and the same machine, is exactly what I want, just a backdoor for the site.

But the authentication is indeed the big con. When the site is using forms authentication the service will be using windows authentication as well. It is somewhat hilarious to see your site login screen pop up in VS. So it's not a good idea.

Service is not autonomous. It's dependent from the site.
When the site uses forms authetication it's gonna be at least a hell of a web.config

My next post will be on Christians Contract First tool.

Published Jan 16 2006, 09:05 AM by pvanooijen

Filed under: ASP.NET

Comments

DaveNetNoob said:

Off the top of my head;

1. You are limited to deploying the web app and the web service on the same machine.
2. The authentication mechanism may not be shareable between the web service and web app directory.

Please do tell how you get on (good but more importantly bad).

# January 16, 2006 11:19 AM

DaveNetNoob said:

In you config section you can set a specific auth mode for a page:

<location path="NewWebService.asmx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>

# January 16, 2006 4:01 PM

pvanooijen said:

No, that does not work.

You cannot change the authorization within an IIS application. Try it.

# January 18, 2006 6:44 AM

DaveNetNoob said:

You cannot change the 'authentication' but you can change the 'authorization' BUT you are right it makes a fundamental difference in this case!

Dave

PS. I made the phrase 'Auth' ambiguous, my mistake.

# January 18, 2006 5:20 PM

Peter's Gekko said:

Recently I was in the need of a web service. At first sight I only needed a back door on a website to...

# January 20, 2006 8:09 AM

Peter's Gekko said:

When you create a web service with Visual Studio the code template throws you straight into the code of a class. By writing out the code you're defining and implementing the service in one go. At first sight a web service is no more than a bunch of RPC invocations. In the real world web services are a matter of services sending each other (XML) messages. Christian Weyer created the Web Services Contract First tool, an add-in for Visual Studio. Using this tool you start with defining the messages being exchanged between web service and its consumer and end with a generated proxy and a stub class which take care of sending and receiving these messages. This approach to web services fits far better in a good architectural view of your services and applications.

# January 20, 2006 11:18 AM

Peter's Gekko said:

# January 20, 2006 11:21 AM

Peter's Gekko said:

Author: <a href="blogs/peter.van.ooijen">Peter Van Ooijen</a><br />When you create a web service with Visual Studio the code template throws you straight into the code of a class. By writing out the code you're defining and implementing the service in one go. At first sight a web service is no more than a bunch of RPC invocations. In the real world web services are a matter of services sending each other (XML) messages. Christian Weyer created the Web Services Contract First tool, an add-in for Visual Studio. Using this tool you start with defining the messages

# January 20, 2006 11:24 AM

Peter's Gekko said:

When you create a web service with Visual Studio it throws you straight into the code of a class. Writing out the code you're defining and implementing the service in one go. At first sight the service is no more than RPC invocations. In the real world web services are a matter of services sending each other (XML) messages. Christian Weyer created WSCF, an add-in for Visual Studio. Using this you start with defining the messages being exchanged between service and its consumer and end with generated proxy and a stub which take care of sending and receiving them. This approach fits far better in a good architectural view of your services and applications.

# January 20, 2006 11:24 AM