WCF Bindings - so many! How do I choose one?

Question

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 1

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.

Answer 2

Indeed there are many options.

Binding

The bindings available from WCF are a set of protocols for common scenarios. It specifies transport, message and security information.

When choosing a binding, you need to find out what feature you need from it. e.g. you may need a way to

• authenticate the clients since you do not want everyone is able to use your service.
• the data might need to be encrypted.
• the service requires to be interoperable for clients from other platform.
• the overhead of message is becoming an issue.

If you know the clients are always from dot net, you could utilize net tcp binding, that is faster than basicHttpbinding. However, basicHttpBinding is an interoperable protocol, even php or java clients can talk to it without problem.

Define your own requirements for the service and then look for the existing binding to fit your needs, if there isn't any existing binding, you can create your own binding which is called custom binding, it could combine features from different binding together to achieve the objective.

Hosting

IIS is more scalable. If your service does not require the state which has to be hosted in a long run daemon process(windows service or console app), IIS is the choice since it is easy to enable compression and encrytion for your services.

More on Binding

If you want your service to be called within Browser i.e. javascript WebHttpBinding is good one that dot net defined for you. You can utilize enbableWebScript to make the service understands JSON for javascript.

Availability

If one specific binding can not fulfill all the requirements, you can expose each service in different binding at different endpoints. e.g. host/soap host/nettcp host/json