2

I posted about this before to a degree, but after a few days of reading I have a better understanding of WCF and would like to get a bit of feedback before I start working on it.

I basically need to develop a server/client system. The "server" application (c# net console app) will be ran on a machine with a MySQL database, all software installation packages, and whatever else we need local to it. The "client" application (c# net console app) will be ran on the rest of our machines, and will maintain a direct connection to the server software. Using a web front-end, our administrators will be able to install software packages to the clients, create new services, etc.

Since we own all of the machines, and have to configure them anyways, Server Push is not a problem. We don't have to worry about firewalls or any sort of NAT settings as we can just go in and open the ports required for it to operate.

What initially confused me about WCF is I assocated a "WCF Service" with a server. However, since the majority of operations are actually going to be run on the "WCF Service", this is my logic.

1) Make the "client" application actually a "WCF Service" so that the exposed functions are actually ran on the proper machines.

2) Have the "server" application actually a "WCF Client", and issue all of the instructions/commands from here, and just use the return value to update the database/etc.

Would this be the proper method to go follow or should I look into WCF Duplex (Looked extremely confusing at first glance) or just start with raw sockets?

stivlo
  • 83,644
  • 31
  • 142
  • 199
  • I was going to answer this with "Of course!" ... and then I realised I have been trying to do the exact same thing with the WCF Duplex service, which would be far less appropriate in a fully controlled network. Thanks for the lateral thinking. – ocodo Mar 11 '11 at 09:08
  • Not a problem, took me long enough to think of it in a reverse scenario, but glad it will work for us both! –  Mar 11 '11 at 09:13

2 Answers2

1

from what I gatther you're trying to do, you're correct. That is the client machines should really have a TCP/IP "server" running on them, and the centeral server machine would have the Tcp/IP "Client".

That way the TCP/IP client (The app running on your server machine) can initiate calls to each of the client machines.

Keep in mind also that a single application can be both a tcp/ip client and server. So your app that's running on the server machine could in turn also be a tcp/ip server that your admin uses to do stuff using a browser. Which effectively means that service is an HTTP service.

Shiv Kumar
  • 9,599
  • 2
  • 36
  • 38
  • Great, that is what I was thinking but wanted to make sure. –  Mar 11 '11 at 09:11
  • Woops, accidently sent that. Anyways, that is the part I am not too clear on yet. I believe what I want is to have an ASP web front end as I understand it, this would be very easy to setup to provide a web front-end for my console application. If I understand correctly, the ASP web application would basically just plug right into my "server" console application? –  Mar 11 '11 at 09:12
  • @Brett, an ASP.NET application is really (for the most part) a "server" application with the browser being the "client" that initiates calls on the "server". Now within an ASP.NET application (the server side) you could have a WCF client application that makes calls out to other tcp/ip "server" applications. So for instances, from a web browser (front end), you can click a button say, and that makes a request out to the ASP.NET server side. In turn the server side could make a call out to any number of other tcp/ip "servers". Does that make sense? – Shiv Kumar Mar 11 '11 at 10:11
  • @Brett, Anthoer thing to note is that your WCF TCP/IP "Server" applications (the ones sitting on the client machines) can in turn make calls out to the ASP.NET server application too. So eseentially, you'd have an ASP.NET application that can talk to something on your client machines and to your database and you'll also have WCF applications on each client machine that are primarily tcp/IP "server" application but can make TCP/IP (in this case http specifically) calls out to the ASP.NET server application which in turn can – Shiv Kumar Mar 11 '11 at 10:16
  • either talk to other client machines or database via the ASP.NET server application. – Shiv Kumar Mar 11 '11 at 10:17
0

So, it is not a client/server thing. It is a hub-and-spoke arrangement of distributed computing. I think, WCF can very well be used. You have multiple servers and a coordinator (the client to all of these servers) that gets the work done from various servers and update the database.

So WCF is well-suited for you. The benefit of WCF is the easy configurability and handling the communication part. You don't have to take much pain for the management of sockets.

Kangkan
  • 15,267
  • 10
  • 70
  • 113
  • Alright, that is perfect. The Duplex looked like a confusing nightmare, and I really didn't need the complexity of it, so when I started thinking of the Service/Client in a reverse arrangement, it seemed to make perfect sense. –  Mar 11 '11 at 09:13
  • In service scenario, server need not be the fat guy and the client be the leaner one. In real life also, the service rendering is generally done by the leaner one! For extending the design, you can think of another service running in the client machine (with our reversed arrangement of client/server) that updates the database. This will enable you to deploy the database elsewhere and the client become a lightweight coordinator. – Kangkan Mar 11 '11 at 09:25