Web Service or WebServices

I am in the process of creating an application which will communicate with a single server where WCF Web Service(s) would be installed. I am a little 开发者_运维知识库new to this process and was wondering which of these two options would be better in the long run to handle the load for a significant amount of users:

1- Create and install a single Web Service on a multi-core server for all of the client applications to communicate with.

2- Create and install multiple Web Services on a multi-core server, each to communicate with different modules inside of the client application.

All-in-all I'm just trying to figure out whether in processing time and with a large number of users whether there is a significant difference between options 1 and 2, or if option 2 would just create an unnecessary programming headache.

Thanks,

Patrick

---

The advantage of having multiple web services would be that each can have their own application pool (i.e. worker process) in IIS. So you can recycle one application pool for one web service without affecting the others.

The advantage of having a single web service would be potentially easier maintenance, since the code is in one file, etc. Of course, if it's a lot of code, this can make maintenance harder too.

So the question is, what's the right level of granularity?

You can split the web services up per business function, and I've found that this is a good approach. For example, if you have some business methods that deal with invoicing, you could put those into an Invoicing web service.

If you have other business methods that deal with shipping orders, you could put those into a Shipping web service.

This creates a nice split, in my opinion, and also lets you leverage the application pool advantages discussed earlier.

Example You can see a real world example of this type of split with FedEx. Note how they split their web services up by shipping, tracking and visibility, etc.