which WCF binding for LAN Client application
I am developing a LAN based Counter Billing Application with around 10 clients. Basically 1 server will have SQL-Server Express installed where all billing details will be stored. So all 10 clients will be communicating with server now & then for product information and billing. I am novice in WCF and read some articles on WCF from various sources. What I think NetTCPBinding will be good for this purpose!!!. My question is "Does NetTCPBinding is good for this purpose?". I want to keep it simple. One more thing do I need to write different WCF services for client app PC and Server app PC for communication?
If my question sounds confusing then in simple words I want to insert and updates SQL-Server 2005 tables (Installed on Server) from my LAN Client PCs for billing purpose. How I can do that using WCF...
For a LAN based application, I'd strongly recommend netTcpBinding since it's significantly faster than HTTP based bindings (because it encodes the messages in a binary instead of text format), and it supports all the features like sessions, streaming etc. you might ever want.
The only minor wrinkle is that you cannot host your WCF services in IIS6 (Win Server 2003/2003 R2) if you're using netTcpBinding - you either need to use IIS 7 (Win Server 2008 or 2008 R2) or self-host the WCF service in e.g. a Windows service (works on any Windows Server OS version).
Juval Lowy has a really good and simple flow chart in his Programming WCF Services book (the standard book for medium to advanced topics) which helps you easily pick the most appropriate binding - find it in this article by Juval.
The NetTcpBinding generates a run-time communication stack by default, which uses transport security, TCP for message delivery, and a binary message encoding. This binding is an appropriate system-provided choice for communicating over an Intranet.
More generally, the HTTP system-provided bindings such as WSHttpBinding and BasicHttpBinding are configured to turn things on by default, whereas the NetTcpBinding binding turns things off by default so that you have to opt-in to get support, for example, for one of the WS-* specifications. This means that the default configuration for TCP is faster at exchanging messages between endpoints than that configured for the HTTP bindings by default.
I found the CodePlex guides invaluable when starting out with WCF, as they provide details and explainations about all facets of WCF, with guides on how to setup and configure different scenarios:
You should look at the chapters under "Part III - Intranet Application Scenarios" on the above page.
One of the things I like about WCF is that choices like HTTP vs TCP are oftentimes a non-issue: changing the binding can be as simple as updating config files if you're careful.
The other caveat is that TCP binding's encoding will limit you to what clients can interact with your WCF server. If you envision ever having to support a non-.NET client, you'll want to go with HTTP to ensure universal capability.