Take the 2-minute tour ×

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)?

share|improve this question

4 Answers 4

up vote 9 down vote accepted

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.

share|improve this answer
Interesting. For .NET to .NET where I know I don't care about compatibility with non .NET clients I usually use TCP binding, which seems to be right according to the flowchart. weblogs.asp.net/spano/archive/2007/10/02/…. Your suggestion is certainly the simplest, but if you have a good book/examples/know what you're doing getting other bindings working isn't much more effort. I think the case for choosing IIS is weaker now Windows Process Activation Service (WAS) is around. –  RichardOD Sep 18 '09 at 14:34

Indeed there are many options.


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.


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.


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

share|improve this answer

I would suggest referring the book "Programming WCF Services" by Juval Lowy.

He walks through a decision chart to help you decide which binding to use. You can also find his article on bindings here


share|improve this answer
Yes- the flow chart is very handy. –  RichardOD Sep 18 '09 at 14:23
And so is the book- not suitable for beginners though –  RichardOD Sep 18 '09 at 14:39

Extract from the book WCF4 of wros " All these built-in bindings are built on standars that work for specific scenarios, but will also work i you choose the wrong or less-efficient one. So how do you choose hich one is right for you?

The most obvious decisión s if you need to interact with non-WCF applications. If your service is to communicate with WCF clients, then you can use on of the bindings prefixed with "net." Remember you can define several endpoints for the same service which would use different bindings. This allows you to take advantage of performance optimizations for WCF clients, but still provide support for ASMX services and WS-* standards. These provide further security and other features which many clients take advantage f.

For example, if you want to establish a WCF to WCF communication, choosing a NetTcpBinding with a binary encoding akes the communication four or five time faster tan a BasicHttpBinding with text encoding.

These WCF-provided bindings should cover most cases that you need:however, if you need to change or créate an entirely ne binding, WCF allows you do this very simply"

share|improve this answer

Your Answer


