Should we create local web services within an Asp.Net application which are called by the application itself?

Question

Hi,

I've moved to a new project team and while going over the codebase, found that the team have created a number of local web services which then get called by server code in other web pages within the same application.

I'm somewhat puzzled by this architecture, as I'd thought local web services were something you'd then access from the client, or from other distinct applications.

However by communicating with the local web service from other server code in our application, it seems to me that we're going through the rigmarole of wrapping the message into XML/Soap and thru the html stack to the service and then back again and will end up adding a shedful of time and slow down the application.

Have mentioned my concerns on this to my new colleagues, and theres been a bit of debate. Just wondered what others thought of this approach and am I right to be concerned?

Thanks

Mickey

Answer 1

Even though yoru web service gets called by 1 client at the moment, perhaps there will be other clients in the future. From that point of view I'd be more concerned about whether the application partition makes sense architecturally. That is, is that a good separation of concerns? Of course performance is another consideration.

Answer 2

Using local web services is not a bad thing. It can increase the modularization (increased cohesion, decreased coupling) of a given application. Moving the target code into a web service can be thought of like creating a shared library (DLL, .so, etc.) with the important benefit of being easily called from different processes. It's like getting RPC or DCOM for much less headache. As long as you keep the calling convention clear, it shouldn't be a problem to create applications that are almost entirely made up of web service calls. It's the application version of Mash-ups.

Answer 3

I think you are right to be a bit surprised that the team would implement a web service call within the application - why pay the overhead?

The real problem, though, isn't necessarily the web service call - this is a legitimate technique. The greater problem is likely to be in your division of responsibilities. The web service handler is akin to the UI in a standard page: there to handle the interaction with the outside world. It should be passing off the arguments it receives to a business logic object.

The advantages of a separate business logic object are manifold: easier unit testing and the ability to call directly into the same function from within your code are the most prominent. Thus, they should probably refactor the logic out of the web service and into a business logic object and call the object directly rather than incurring the overhead of the web service call.