Self hosted WCF ServiceHost/WebServiceHost Concurrency/Peformance Design Options (.NET 3.5)

Question

So I'll be providing a few functions via a self hosted (in a WindowsService) WebServiceHost (not sure how to process HTTP GET/POST with ServiceHost), one of which may be called a large amount of the time. This function will also rely on a connection in the appdomain (hosted by the WindowsService so it can stay alive over multiple requests).

I have the following concerns and would be oh so thankful for any input/thoughts/comments:

• Concurrent access - how does the WebServiceHost handle a bunch of concurrent requests. Are they queued and processes sequentially or are new instances of the contracts automagically created?
• WebServiceHost -> WindowsService communication - I need some form of communication from the WebServiceHost to the hosting WindowsService for things like requesting a new session if one does not exist. Perhaps implementing a class which extends the WebServiceHost with events which the WindowsService subscribes to... (unless there is another way I can set off an event in the WindowsService when a request is made...)
• Multiple WebServiceHosts or Contracts - Would it give any real performance gain to be running multiple WebServiceHost instances in different threads (one per endpoint perhaps?) - A better understanding of the first point would probably help here.
• WSDL - I'm not sure why (probably just need to do more reading), but I'm not sure how to get the WebServiceHost base endpoint to respond with a WDSL document describing the available contract. Not required as all the operations will be done via GET requests which will not likely change, but it would be nice to have...

That's about it for the moment ;) I've been reading a lot on WCF and wish I'd gotten into it long ago, but definitely still learning.

Answer 1

Concurrent access - this is something you can set using ServiceBehaviorAttribute. there are a number of options -- you can have WCF create a new instance of your service class for each incoming request, or you can have a single instance handle all requests. Additionally you can tell WCF whether to pass you the requests serially or concurrently.

WebServiceHost -> WindowsService communication. Two approaches spring to mind: WCF supports a mode called "well known instance" where you pass an instance of your service to the ServiceHost constructor instead of passing a Type and letting WCF instantiate it for you. With this mode you can preconfigure your service instance with a reference back to your hosting code (alternatively you could use events). An alternative if you want to preserve instancing flexibility would be to have a static method in your hosting code that the WCF service could call back into.

Multiple WebServiceHosts or Contracts - really no advantage to having more than one ServiceHost instance. see also this SO thread: http://stackoverflow.com/questions/2131796/what-are-the-benefits-for-several-servicehosts-does-one-servicehost-support-seve.

WSDL - While you can enable WSDL by turning on metadata publishing (http://msdn.microsoft.com/en-us/library/ms788760.aspx), WSDL support is intended for SOAP-based services, not pure HTTP GET/POST. The WSDL that gets auto-generated for your service will likely not be very useful.