Is this what I'd use WCF for?
-
I'm not sure WCF is the way I should go here but I'm keen to get to learn a new technology so I thought I should investigate it at least. We are developing a system in which we need a server-side application (with GUI, so not a Windows service) and several client side applications that communicate with this server side application. All of this happens on the internal network so I figured that TCP binding might be suitable. The one approach would be to write some TCP/IP server routines on the server-side application and have the clients communicate with it over TCP sockets for which we'd have to implement certain messaging. What I dislike about this approach is the fact that all comms will be request-response type. In other words, the server can only send messages to the client if the client sent a message to the server. So the possibility of full-duplex comms of WCF seems like a perfect solution. The thing I'm unsure of is whether WCF would allow for a server-side application that has a GUI and allows for user interaction. I thought I might try getting to know WCF first by writing a small mini system (in C#), the sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer. A number of other computers in the office then has a client application. The client application can send a message to the server application to subscribe itself to the notifications. When the sandwich lady arrives the receptionist can then open the GUI of the application on her machine and click a button which triggers the app to send a message to all the clients that has subscribed which in turn pops up a notification on the client machine. I realise there might be better ways to achieve this particular solution but it is a reasonable analogy of what we ultimately want to achieve with out bigger system so I figure I might gain the skills I need if I can figure out how to write this little system. My question is, could someone tell me please whether WCF is indeed the technology that should be used for this? I have only just started reading up on it but I am getting the impression that with WCF, the server side application will have to take the form of a service, not a desktop application. Could anyone give me some clarity on this please and possibly point me in the right direction for what I'm trying to achieve? TIA
-
I'm not sure WCF is the way I should go here but I'm keen to get to learn a new technology so I thought I should investigate it at least. We are developing a system in which we need a server-side application (with GUI, so not a Windows service) and several client side applications that communicate with this server side application. All of this happens on the internal network so I figured that TCP binding might be suitable. The one approach would be to write some TCP/IP server routines on the server-side application and have the clients communicate with it over TCP sockets for which we'd have to implement certain messaging. What I dislike about this approach is the fact that all comms will be request-response type. In other words, the server can only send messages to the client if the client sent a message to the server. So the possibility of full-duplex comms of WCF seems like a perfect solution. The thing I'm unsure of is whether WCF would allow for a server-side application that has a GUI and allows for user interaction. I thought I might try getting to know WCF first by writing a small mini system (in C#), the sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer. A number of other computers in the office then has a client application. The client application can send a message to the server application to subscribe itself to the notifications. When the sandwich lady arrives the receptionist can then open the GUI of the application on her machine and click a button which triggers the app to send a message to all the clients that has subscribed which in turn pops up a notification on the client machine. I realise there might be better ways to achieve this particular solution but it is a reasonable analogy of what we ultimately want to achieve with out bigger system so I figure I might gain the skills I need if I can figure out how to write this little system. My question is, could someone tell me please whether WCF is indeed the technology that should be used for this? I have only just started reading up on it but I am getting the impression that with WCF, the server side application will have to take the form of a service, not a desktop application. Could anyone give me some clarity on this please and possibly point me in the right direction for what I'm trying to achieve? TIA
Sounds simple enough. You can self host WCF services so it is no matter if you need a GUI or not. This Tutorial[^] for example runs this service inside a Console app. The app could of course be a WPF, Winform etc. Let us know if you get stuck or something, but as for your question the tech is right for you.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
I'm not sure WCF is the way I should go here but I'm keen to get to learn a new technology so I thought I should investigate it at least. We are developing a system in which we need a server-side application (with GUI, so not a Windows service) and several client side applications that communicate with this server side application. All of this happens on the internal network so I figured that TCP binding might be suitable. The one approach would be to write some TCP/IP server routines on the server-side application and have the clients communicate with it over TCP sockets for which we'd have to implement certain messaging. What I dislike about this approach is the fact that all comms will be request-response type. In other words, the server can only send messages to the client if the client sent a message to the server. So the possibility of full-duplex comms of WCF seems like a perfect solution. The thing I'm unsure of is whether WCF would allow for a server-side application that has a GUI and allows for user interaction. I thought I might try getting to know WCF first by writing a small mini system (in C#), the sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer. A number of other computers in the office then has a client application. The client application can send a message to the server application to subscribe itself to the notifications. When the sandwich lady arrives the receptionist can then open the GUI of the application on her machine and click a button which triggers the app to send a message to all the clients that has subscribed which in turn pops up a notification on the client machine. I realise there might be better ways to achieve this particular solution but it is a reasonable analogy of what we ultimately want to achieve with out bigger system so I figure I might gain the skills I need if I can figure out how to write this little system. My question is, could someone tell me please whether WCF is indeed the technology that should be used for this? I have only just started reading up on it but I am getting the impression that with WCF, the server side application will have to take the form of a service, not a desktop application. Could anyone give me some clarity on this please and possibly point me in the right direction for what I'm trying to achieve? TIA
I'll second Collin's answer. I am actually doing this very thing now. I have a Windows Forms app hosting a WCF server, a console app hosting another WCF server, and several WCF clients. I did mine this way because I needed to transmit objects across the TCP/IP network, with the objects being .NET objects.
-
I'm not sure WCF is the way I should go here but I'm keen to get to learn a new technology so I thought I should investigate it at least. We are developing a system in which we need a server-side application (with GUI, so not a Windows service) and several client side applications that communicate with this server side application. All of this happens on the internal network so I figured that TCP binding might be suitable. The one approach would be to write some TCP/IP server routines on the server-side application and have the clients communicate with it over TCP sockets for which we'd have to implement certain messaging. What I dislike about this approach is the fact that all comms will be request-response type. In other words, the server can only send messages to the client if the client sent a message to the server. So the possibility of full-duplex comms of WCF seems like a perfect solution. The thing I'm unsure of is whether WCF would allow for a server-side application that has a GUI and allows for user interaction. I thought I might try getting to know WCF first by writing a small mini system (in C#), the sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer. A number of other computers in the office then has a client application. The client application can send a message to the server application to subscribe itself to the notifications. When the sandwich lady arrives the receptionist can then open the GUI of the application on her machine and click a button which triggers the app to send a message to all the clients that has subscribed which in turn pops up a notification on the client machine. I realise there might be better ways to achieve this particular solution but it is a reasonable analogy of what we ultimately want to achieve with out bigger system so I figure I might gain the skills I need if I can figure out how to write this little system. My question is, could someone tell me please whether WCF is indeed the technology that should be used for this? I have only just started reading up on it but I am getting the impression that with WCF, the server side application will have to take the form of a service, not a desktop application. Could anyone give me some clarity on this please and possibly point me in the right direction for what I'm trying to achieve? TIA
Dewald wrote:
In other words, the server can only send messages to the client if the client sent a message to the server.
That statement isn't any more or less true for WCF using TCP. And without qualification it is false for TCP. A tcp connection always has two ends. One end accepts (server) and one ends initiates (client.) Most of the useful WCF protocols use TCP. The protocols that don't use TCP are either limited significantly by the underlying technology or are really hard to get to work.
Dewald wrote:
he sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer
What happens if the receptionist is late? Thus the application will not be running.
Dewald wrote:
My question is, could someone tell me please whether WCF is indeed the technology that should be used for this?
Your simple problem description doesn't preclude the use.
-
I'm not sure WCF is the way I should go here but I'm keen to get to learn a new technology so I thought I should investigate it at least. We are developing a system in which we need a server-side application (with GUI, so not a Windows service) and several client side applications that communicate with this server side application. All of this happens on the internal network so I figured that TCP binding might be suitable. The one approach would be to write some TCP/IP server routines on the server-side application and have the clients communicate with it over TCP sockets for which we'd have to implement certain messaging. What I dislike about this approach is the fact that all comms will be request-response type. In other words, the server can only send messages to the client if the client sent a message to the server. So the possibility of full-duplex comms of WCF seems like a perfect solution. The thing I'm unsure of is whether WCF would allow for a server-side application that has a GUI and allows for user interaction. I thought I might try getting to know WCF first by writing a small mini system (in C#), the sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer. A number of other computers in the office then has a client application. The client application can send a message to the server application to subscribe itself to the notifications. When the sandwich lady arrives the receptionist can then open the GUI of the application on her machine and click a button which triggers the app to send a message to all the clients that has subscribed which in turn pops up a notification on the client machine. I realise there might be better ways to achieve this particular solution but it is a reasonable analogy of what we ultimately want to achieve with out bigger system so I figure I might gain the skills I need if I can figure out how to write this little system. My question is, could someone tell me please whether WCF is indeed the technology that should be used for this? I have only just started reading up on it but I am getting the impression that with WCF, the server side application will have to take the form of a service, not a desktop application. Could anyone give me some clarity on this please and possibly point me in the right direction for what I'm trying to achieve? TIA
WCF Peer channels is soothing you could explore - http://msdn.microsoft.com/en-us/library/bb756931.aspx[^].
WP Apps - Color Search | Arctic | XKCD | Sound Meter | Speed Dial
-
Dewald wrote:
In other words, the server can only send messages to the client if the client sent a message to the server.
That statement isn't any more or less true for WCF using TCP. And without qualification it is false for TCP. A tcp connection always has two ends. One end accepts (server) and one ends initiates (client.) Most of the useful WCF protocols use TCP. The protocols that don't use TCP are either limited significantly by the underlying technology or are really hard to get to work.
Dewald wrote:
he sandwich lady notification system, consisting of a "server" side application which runs on the receptionist's computer
What happens if the receptionist is late? Thus the application will not be running.
Dewald wrote:
My question is, could someone tell me please whether WCF is indeed the technology that should be used for this?
Your simple problem description doesn't preclude the use.
jschell wrote:
That statement isn't any more or less true for WCF using TCP.
And without qualification it is false for TCP. A tcp connection always has two ends. One end accepts (server) and one ends initiates (client.)OK, maybe I need to explore this to make sure I understand it correctly. My understanding is that, with TCP/IP, a message can only be sent from server->client if the client requested it from the server. in the example of my sandwich lady application, when the receptionist hits the button to notify everybody of the sandwich lady's arrival there is no way that the server can initiate a message to be sent to the client. The clients will have to continually poll the server for a notification. This means the client applications will have to sit on a timer (which consumes CPU/memory resources) so that it can continually message the server (which consumes network bandwidth) to which the server can respond if appropriate. It also means the client can only act on the notification every 30sec, 1min or however quick you choose to set up the timer but more often equals more resources wasted and less often means longer delay before the client knows of the sandwich lady's arrival. I was of the understanding, but I could be wrong, that with WCF this can be implemented differently. Once a connection is established between a client and a server, the server can initiate a message to the client which will call a callback function in the client application. The difference is that the client sits and does nothing (other than looping through the main UI thread) until the server sends it a message whenever it decides to do so. So the server still accepts and the client initiates but, once the connection has been established, either the server or the client can initiate a message. Have I got this all wrong?
jschell wrote:
What happens if the receptionist is late? Thus the application will not be running.
It doesn't matter. This sandwich lady system is just a means for me to get to grips with the technology. The eventual system will be far more robust. But yes, if the receptionist is late, the client side applications will have no server side application to connect to and will either notify you as such and terminate or it will retry the connection every 10 minutes or so. Thanks
-
jschell wrote:
That statement isn't any more or less true for WCF using TCP.
And without qualification it is false for TCP. A tcp connection always has two ends. One end accepts (server) and one ends initiates (client.)OK, maybe I need to explore this to make sure I understand it correctly. My understanding is that, with TCP/IP, a message can only be sent from server->client if the client requested it from the server. in the example of my sandwich lady application, when the receptionist hits the button to notify everybody of the sandwich lady's arrival there is no way that the server can initiate a message to be sent to the client. The clients will have to continually poll the server for a notification. This means the client applications will have to sit on a timer (which consumes CPU/memory resources) so that it can continually message the server (which consumes network bandwidth) to which the server can respond if appropriate. It also means the client can only act on the notification every 30sec, 1min or however quick you choose to set up the timer but more often equals more resources wasted and less often means longer delay before the client knows of the sandwich lady's arrival. I was of the understanding, but I could be wrong, that with WCF this can be implemented differently. Once a connection is established between a client and a server, the server can initiate a message to the client which will call a callback function in the client application. The difference is that the client sits and does nothing (other than looping through the main UI thread) until the server sends it a message whenever it decides to do so. So the server still accepts and the client initiates but, once the connection has been established, either the server or the client can initiate a message. Have I got this all wrong?
jschell wrote:
What happens if the receptionist is late? Thus the application will not be running.
It doesn't matter. This sandwich lady system is just a means for me to get to grips with the technology. The eventual system will be far more robust. But yes, if the receptionist is late, the client side applications will have no server side application to connect to and will either notify you as such and terminate or it will retry the connection every 10 minutes or so. Thanks
Dewald wrote:
My understanding is that, with TCP/IP, a message can only be sent from server->client if the client requested it from the server.
That isn't true. Although TCP can be set up as a one way traffic it requires specifically doing that and almost is never done that way. You can of course write the client code such that it does exactly that. It sends a message and then waits for a response. But that is a choice not a requirement.
Dewald wrote:
there is no way that the server can initiate a message to be sent to the client
As a guess you are actually referring to the problem of having the server initiate a connection to the client. In that case your client would be the 'tcp server' and your server would be the 'tcp client'. That scenario is generally a problem because the server (your server) doesn't want to track the IPs of the clients and/or can't connect to them anyways. That won't change with WCF.
Dewald wrote:
(which consumes CPU/memory resources)
A trivial amount especially in terms of this discussion. A standard windows box on a standard corporate network is doing thing like this all the time. Maybe you should look at message queues as well. They still use TCP but they hide it behind a different functional facade.
-
Dewald wrote:
My understanding is that, with TCP/IP, a message can only be sent from server->client if the client requested it from the server.
That isn't true. Although TCP can be set up as a one way traffic it requires specifically doing that and almost is never done that way. You can of course write the client code such that it does exactly that. It sends a message and then waits for a response. But that is a choice not a requirement.
Dewald wrote:
there is no way that the server can initiate a message to be sent to the client
As a guess you are actually referring to the problem of having the server initiate a connection to the client. In that case your client would be the 'tcp server' and your server would be the 'tcp client'. That scenario is generally a problem because the server (your server) doesn't want to track the IPs of the clients and/or can't connect to them anyways. That won't change with WCF.
Dewald wrote:
(which consumes CPU/memory resources)
A trivial amount especially in terms of this discussion. A standard windows box on a standard corporate network is doing thing like this all the time. Maybe you should look at message queues as well. They still use TCP but they hide it behind a different functional facade.
Thanks, I'll definitely look into message queues also. Of course you're right as regards TCP/IP being full duplex. My misunderstanding comes from the typical way in which I've always been used to implementing the application layer protocol on top of the TCP layer. In it's most basic form TCP comms consist basically of two streams, one upstream and one downstream. The server can put any message at any time into the downstream while the client can put any message at any time into the upstream. So yes, that is the textbook definition of full duplex. What makes WCF more suitable to me (I think) is the fact that the implementation of all this seems to be much easier. With TCP, I'd have to write a thread that constantly reads the downstream and decide what is a response to a message that was sent on the upstream and what is a message that simply arrives unsolicited. With WCF the response to an upstream message comes in the form of a return value to the function that is called while an unsolicited message comes in the form of a callback function that is called.