views:

266

answers:

3

I have developed a windows service which reads data from a database, the database is populated via a ASP.net MVC application.

I have a requirement to make the service re-load the data in memory by issuing a select query to the database. This re-load will be triggered by the web app. I have thought of a few ways to accomplish this e.g. Remoting, MSMQ, or simply making the service listen on a socket for the reload command.

I am just looking for suggestions as to what would be the best approach to this.

A: 

I'd use standard TCP sockets - this will survive all sorts of moving of components, and minimize configuration issues IMHO.

Harper Shelby
+1  A: 

Simply host a WCF service inside the Windows Service. You can use netTcpBinding for the binding, which will use binary over TCP/IP. This will be much simpler than sockets, yet easier to develop and maintain.

John Saunders
That is one option I have not considered, thanks for the suggestion I will look into it.
+2  A: 

How reliable does the notification has to be? If a notification is lost (lets say the communication pipe has a hickup in a router and drops the socket), will the world end come or is business as usual? If the service is down, do notifications from the web site ned to be queued up for when it starts up, or they can e safely dropped?

The more reliable you need it to be, the more you have to go toward a queued solution (MSMQ). If reliability is not an issue, then you can choose from the mirirad of non-queued solutions (remoting, TCP, UDP broadcast, HTTP call etc).

Do you care at all about security? Do you fear an attacker my ping your 'refresh' to death, causing at least a DoS if not worse? Do you want to authenticate the web site making the 'refresh' call? Do you need privacy of the notifications (ie. encryption)? UDP is more difficult to secure (no session).

Does the solution has to allow for easy deployment, configuration and management on the field (ie. is a standalone, packaged, product) or is a one time deployment that can be fixed 'just-in-time' if something changes?

Withous knowing the details of all these factors, is dififcult to say 'use X'. At least one thing is sure: remoting is sort of obsolete by now.

My recommendation would be to use WCF, because of the ease of changing bindings on-the-fly, so you can test various configurations (TCP, net pipe, http) w/o any code change.

BTW, have you considered using Query Notifications to detect data changes, instead of active notifications from the web site? I reckon this is a shot in the dark, but equivalent active cache support exists on many databases.

Remus Rusanu
A lot of great information there, thanks a lot.This is not business critical so I don't care about notifications being queued.I am going to investigate the WCF route although my experience with it is very limited. Query Notifications also looks interesting.
Give WCF a shot, is worth it. If no WCF, then either TCP or even UDP broadcast. Remoting and MSMQ seem overkill.
Remus Rusanu