I have created a windows service to serve as an "input manager" to a system. What is does is not really important. It just reads records in from a SQL server table, transforms the data into a new form and puts it in another SQL server table.
What I would like to do is create a service control program that can talk to my service and get information on what record is currently being processed and, perhaps change processing settings.
I looked into creating a Sevice Controller Program (SCP) but you really can just start and stop the service and send it an integer as a command with the ExecuteCommand() method.
As I said, I want to do more. Ideally, I'd like to setup a deal where my service has public properties and methods that can be called from an external "control" program. A sample property would just tell me what record is being processed. A sample method may be to tell the service to backup and start processing at a previous record for some reason.
The solution, I would think, would be like an old COM Server. An .EXE that one can get a handle to and the access the methods and properties. In COM you could do this with GetObject() for example.
I have considered writing TCP listeners and have also thought of DCOM, but it seems unnecessary to me if the programs are running on the same machine. I have also considered using Message Queue, which, again, seems like overkill.
An easy solution, of course, is to communicate through a SQL table. However, it seems like a waste to talk between programs like this when I ought to be able to locate the process running in memory and strike up an interprocess communication in memory.
Does anyone know of a way or how in .NET you can have two separate processes talk to each other like a COM Server. Again, these were the good old days, but I used to be able to open MS-Word, for example, and then run a VB
program using the GetObject command that got a handle to Word, and then I could give Word commands. When I closed my VB
program, Word would still be there. This seemed to me like interprocess communication of separate processes, but maybe I was fooled.
Anyway, does anyone have any suggestions? I know I can do this a variety of ways, but there has got to be a better way than using TCP (like SQL Server Enterprise Manager), DCOM, or a shared table.