WCF self hosting, hosting via Console app

I have seen examples, sample codes etc for self hosting WCF services within a console app, windows service etc.

My question is, how wil开发者_如何学Gol this work in production? Will it be efficient? Will it scale?

I m not sure, how it will work, so other question is, will that be single threaded? multi threaded? do i need to manage the multi threading? appdomains?

I prefer hosting with command line, windows service for application related reasons.

My question is,
Will it be efficient? Will it scale?

Yes and yes. But for really large scale apps you should still consider IIS (+WAS).

so other question is, will that be single threaded? multi threaded?

That is determined by the configuration.

Will it be efficient?

It depends on the service implementation, on the maximum number of requests it is able to manage within a specific time-frame. Efficiency is a relative measure: let's assume your service is able to process 20 messages/sec, if your requirement is to be able to process 10 messages/sec, then your service is efficient. But if the requirement is 30, then it is not.

Will it scale?

Once again, it is not related to hosting. Are your services stateless? if not then, they probably won't scale much since load balancing is not possible.

Will it be manageable ?

Probably not: - you need to have a user logged on the server to run the app - it does not auto-start with the server - it cannot auto-restart on failure - it does not create instances of the service pro-actively - it does not provide (without custom code) a way to check the service health

Single instance ? Multiple threads ?

If your service does not maintain state between calls per client, then configure it as "one instance per call and no multithreading" -> No concurrency, high throughput

If your service does maintain state, then configure it as "one instance per session and multithreading" to allow a client to perform concurrent calls. Be careful about concurrency issues and protect your resources.

If your service does not maintain state per client but keeps some global data stored for all calls, consider the "single instance per service and multithreading". Keep in mind the possible concurrency issues. In that you might as well use "one instance per call" and keep the global storage out the service.

A Windows service hosting a WCF endpoint is fine for small services that aren't going to be hit often; you don't have to mess with IIS (which can be a REAL pain IMO). However, there will only be one listener listening, so it's not recommended for a service that is likely to be hit from several places at once (use IIS for that; it sets up an app pool that can handle many simultaneous requests). This model is good for one-on-one interop between two machines; you might set up the service host on a "set and forget" box living out in a warehouse somewhere, and call it to perform simple but custom tasks like rebooting, log dumps, etc.

Avoid having any user app (console or otherwise) host a service endpoint, except for initial proof-of-concept testing. In addition to the single-listener drawback, a user app MUST be run in the context of a logged-in user (not the service users, which are "logged in" as part of Windows startup), and must have custom "keepalive" monitoring; with a service, Windows can be told to simply restart it if it crashes, while it doesn't give a toss about a user app crashing other than to prevent that program taking down the whole OS (and to ask the user if they want to report the crash).