views:

41

answers:

2

In Learning WCF, by Michele Bustamante, there is a section that describes a binding called the NetNamedPipes binding. The book says that this binding can only be used for WCF services that will be called exclusively from the same machine.

Under what circumstances would it make sense to use this? Ordinarily, I would write asynchronous code without using WCF... Why would Microsoft provide something for WCF that can only run on the same machine?

+2  A: 

You probably won't have a service that exposes only a NetNamedPipe endpoint - that doesn't make a lot of sense. But if you run your WCF service on a server, exposing service endpoints out to the world using the usual bindings, and you need e.g. a management or admin console or something like that, running on that same machine, it can make sense to use the NetNamedPipe binding since it's the fastest around.

Another possible scenario that I learned about is having an error collection service - any error or exception that happens is sent to a service to be logged. Again: that service would probably expose several types of endpoints, but if you have other services running on the same server, using NetNamedPipe binding to connect these two services makes a lot of sense.

I don't think you'll use the NetNamedPipe binding an awful lot in your WCF days - but it can definitely make sense in some cases and be quite useful in such specialized scenarios.

marc_s
+4  A: 

Look at it from the other direction. Once the service is built, you can run in in a variety of binding configurations. If it was a remote machine, you could use the HTTP or TCP bindings. Or, the service happened to be running on the same box, you have those options plus the named pipes option. The named pipes is just another option that is provided just in case you are running locally, but you should be able to switch to a different binding if you are running remote.

Yu could start with everything on the same box because you have less traffic, and use named pipes because it was the shortest path to the service. Then, if load demanded it, you can move the service to another box, and then change it to use TCP or HTTP instead.

Mike Mooney