.NET WebService IPC - Should it be done to minimise some expensive operations?

I'm looking at a few different approaches to a problem: Client requests work, some stuff gets done, and a result (ok/error) is returned.

A .NET web service definitely seems like the way to go, my only issue is that the "stuff" will involve building up and tearing down a session for each request. Does abstracting the "stuff" out to an app (which would keep a single session active, and process the request from the web service) seem like the right way to go? (and if so, what communication method)

The work time is negligible, my concern is the hammering the transaction servers in question will probably get if I create/drop a session for each job.

Is some form of IPC or socket based communication a feasible solution here?

Thoughts/comments/exper开发者_StackOverflow中文版iences much appreciated.

Edit: After a bit more research, it seems like hosting a WCF service in a Windows Service is probably a better way to go...

---

well, here we go:

• Do not setup a new communication channel for every request. CLient side / Server side use WCF implementations and make sure the client does not get a new procxy for every call ;) Especially with HTTPS channel setup is expensive.

• Do not call the service ;) SImple as that - make as few calls as POSSIBLE. Have a coarse interface optimized into not making many calls. Allow batching of results. For example "GetInvoice" could be "GetDocuments" - returning not only an invoice, and taking multiple ID's, returning multiple documents. A list of 30 invoices turns from 30 calls into 1. Otherwise a messaging bus approach may work - I use one like that and transport up to 1024 messages per call.

• Try not to use a web service if you have a ton of load. Use WCF and NetTcp binding (which is binary and not using HTTP, so it is not a web service). THe HTTP overhead is tremendous - look up google, someone made a test and we talk net tcp sometimes being about 900 TIMES faster. Especially if you do little work and have lost of users this may increase scalability. Negative - you are only WCF compliant on the client side, no "Web Service" anymore.

This is pretty much all you can do. With different losses, but this is how to get performance up ;) If you talk of purely IPC consider using named pipes, not even net.tcp - named pipes are very efficient (using shared memory between the processes), but limited to the same machine in the .NET implementation.