Is a WCF service right for my requirements?

Question

I've been researching networking techniques in VB.net, specifically the best way for application A to send data to application B.

From my research I've come across several options and I've decided to go with WCF using a basic HTTP protocol - I spent a few hours last night adapting my internal servers IIS configuration and creating a test WCF application to pull a function through and then use it in my application, everything seemed to work without error. (Although me and DNS had some internal struggles for a while...)

I'm now going to attempt to gather system information, simple things like computer name, operating system, running services etc - however I'd like to do this every x amount of time.

Now my question to you guys would be: is WCF a sufficient choice to support the periodic gathering of data and then pushing this out via IIS for application B to receive.

Example workflow:

1. Application A (WCF Service) - Runs functions to collect system information on a 15 minute timer.
2. This is pushed out via a central IIS server
3. Application B (Reference to WCF Service in Application A) - Displays the output of Application A on a label (for example).

Does a WCF service support what I mentioned? This being functions running every 15 minutes?

If I understand the principal idea of a WCF service it's that you can create functions within the WCF service that you can use as a reference for remote applications, although sample code I've looked at produces static data.

The more I think about it the more I think the answer is easy, in my mind I'm saying "Of course I can add a timer or something to re-load the functions (or even the service) and of course when my application uses the reference to pull the data it will be updated.

Key Notes:

• Security of data flow is not an issue.
• Resource usage is a factor.

Thank you for your input and advice.

Answer 1

I would say WCF is not a good choice for this. From your description, it sounds like in WCF terms, you want to push information from the server to the clients. This is the opposite way round from how the majority of WCF services work. Normally, the communication is initiated from the client to the server.

This can be done with WCF using duplex services, but it is relatively complicated.

A much simpler solution would be to use a server push solution like web sockets. In .Net there is an implementation from Microsoft called SignalR

http://www.asp.net/signalr

and (at least one) other implementation called XSockets

http://xsockets.net/

Both implementations are beautifully simple to use.

The implementation would be as follows:

1. The notification "hub" would be hosted in IIS
2. The periodic gathering of data would be done in a Windows Service or simply using a Windows scheduled task. This would gather the data and push it to the hub
3. Clients would register with the hub for updates and receive them whenever the service pushed them

This will be much simpler to implement than a WCF solution in my opinion.

It would work well with

1. Multiple applications gathering the data and sending to the hub
2. Multiple applications getting data from the hub
3. Situations where all the applications sending the data were shut down (as long as the hub was still up)
4. Situations where all the applications receiving the data were shut down

The displaying application would not need to be a WCF client - it could be a browser accessing the hub using JavaScript. Or it could be WCF if you want. Or you could simultaneously support browser and Windows clients.

In addition, it would optimise both your network load and your server workload because it would avoid any polling. The applications receiving the data would get notified when something new was available without having to ask.

One potential disadvantage is that you would have to have .Net 4 or 4.5. For XSockets there is apparently a non-public .Net 2 version, but the NuGet packages are .Net 4.

p.s.

Security of data flow is always an issue :o)

Answer 2

In addition to Mikes nice answer I can point you to two resources. 1: previous question about using WCF to send data to other application Push Data from a WCF Service to Website 2: a comparison table between XSockets and SignalR http://xsockets.net/xsockets-vs-signalr. Bottom line in there is 2 things... First. You need .net 4.5 with IIS8 and win8/2012server to get websockets. Second. XSockets has stateful controllers SignalR does not. The first condition is obviously bad for SignalR, the other one is depending on what you build.

Answer 3

I'd switch the role of service and clients. Because you seem to want to do your data gathering on various clients, you don't want to go through the hassle of setting up and hosting a WCF service on each client.

Instead, write a WCF service that listens on your IIS Server for the periodic system info messages sent by your clients.

You can then create a client that sends status messages to this WCF service. This can for example be a scheduled console application or a Windows Service. You install this client on each server you wish to monitor, the only thing you have to configure is the URL to the central WCF service.

This WCF service in turn writes the messages to a data store like SQL Server. Now when you want to access the logged messages from your monitoring application, expose another service method that returns a list of messages.

You can consume this list of reported status messages from any client, for example a web site or WPF/WinForms application, simply by calling the service.