WCF Bindings - so many! How do I choose one?
We have an R Server (R is a programming language used in statistical analysis) that basically takes a script and a csv file, processes some data and returns results as text.
I need to write a service on the R server so that .net clients (could be .Net Windows Forms, or ASP.Net) can connect to the R server, submit the script and CSV file, and get the results back.
I'm confused by the many different bindings available to me and information on the web seems to be sparse/scattered about what one to choose.
Also, is it best to run the service in IIS, or as a separate "command line" type listener service (the latter seems ugly compared to IIS and I have no idea why anyone would choose to do this if they could run it in IIS)?
Answer
Personally, I'd recommend the simplest binding that gives what you need. I've done quite a lot of WCF (some quite complex), and I've never had to use anything other than BasicHttpBinding; this also allows that greatest possible compatibility with non-.NET clients, and lets you use things like MTOM for efficient binary transfer.
Re hosting; IIS is indeed the simplest for a client/server setup; two particular strengths:
- easy to configure SSL (i.e. you just configure IIS, and WCF will use it)
- easy to load balance (just load balance your web farm)
(I believe WCF running over BasicHttpProfile can also leverage your IIS compression [GZip/Deflate] setup, but don't quote me...)
You might choose to use a standalone host (usually via a windows service) if (for example) you want a long-running stateful server. IIS has this habit (by design) of recycling the app-pools, which isn't good if you were keeping something in memory! Another example is where you want it to be already running for fast "first hit" performance (rather than waiting for IIS/ASP.NET to spin up). An example covering both of these might be hosting a WF (workflow) server.
Again; if you don't need this complexity, go for the simplest option: hosting in IIS.