Using Web Services instead of DLLs

Question

I am looking to see what the consensus is for best practices or just plain sanity in writing apps.

For this example I have the following:

• [HttpHandler]
• ClientRender.ProcessRequest(…)
• ClientFactory.GetInnerInfo(…)
• Services.ServiceConnect.GetCampaignService(…)
• [Web Service]
• Campaign.GetInnerClient(…)
• [Web Service]
• DAL.GetInnerClient(…)
• EnterpriseLibrary.CreateDatabase(…)
• EnterpriseLibrary.GetStroedProcCommand(…)
• EnterpriseLibrary.ExecuteReader(…)
• DAL.PopulateClientCampaignFromReader(…)
• DAL.ClientCampaignFromDataReader(…)
• Return up the call tree…

Questions:

1. What type of performance hits am I incurring by calling a Web Service from within a Web Service from within a HttpHandler?
2. Would it not make more sense to rewrite this as an assembly rather than 2 Web Services? (And put the Web Services on top of the assembly for a WSDL publication.)
3. We also have an admin website that leverages these same assemblies and it takes 2-3 days to “correctly” add a simple CRUD operation on one data entity. Would you argue for moving towards a more direct approach?

Hope this makes sense and feedback is welcome.

Answer 1

It's certainly the case that any valid reason for nesting the web service calls is not apparent.

That doesn't mean there is no reason, only that it's not apparent. You should probably ask those who wrote the service.

Answer 2

All your base are belong to the Architecture Astronauts.

Answer 3

IMHO that's a misunderstanding of what a Web Service should provide. Using a WS to create handle database calls makes no sense. You could:

1. Build separate assemblies for database abstractions and business logic. Methods and classes like "GetStoredProcCommand" should belong to a single assembly, and the business logic should belong to another assembly, or group of assemblies.
2. Use these assemblies as a basis for your WebServices.
3. Before building the WebService, it's imperative to sit down and know who is going to use it, and how. It makes no sense to build a bunch of WebServices if you don't know what it's supposed to do. It will end up being a mess because you'll shove the real functionalities after you built it.
4. If your webservices are supposed to be consumed from internal application, remember that there's a performance impact on using webservices. If you try to do everything via WS, it's going to be slow.