How do I have 2-way communication with Service?

[trant]

I have a Windows Service and I have a GUI Application to manage the Service.
Right now all I can do is start/stop the service or using the custom command
feature I can send an integer to the service.

But I'd like to have more robust communications... I not only want to send
commands to the service but I want to be able to receive updates (like events
when the service experiences a problem which my manager app can then convey
on it's UI). So basiclaly I want 2-way communication and I want to be able to
transmit data instead of just integers between 128 and 255...

What's the best approach to accomplish this?

 

[Jesse Houwing]

Hello trant,

I have a Windows Service and I have a GUI Application to manage the
Service. Right now all I can do is start/stop the service or using the
custom command feature I can send an integer to the service.

But I'd like to have more robust communications... I not only want to
send commands to the service but I want to be able to receive updates
(like events when the service experiences a problem which my manager
app can then convey on it's UI). So basiclaly I want 2-way
communication and I want to be able to transmit data instead of just
integers between 128 and 255...

What's the best approach to accomplish this?

You can easily host a WCF service from your service application and connect
to that from your client.

 

[trant]

Thanks, I will look into that

Is it complicated?

 

[Ignacio Machin ( .NET/ C# MVP )]

Hello trant,

That is pretty much what you can do to "communicate" with the service,
Note that the integer is meant as a way to specify the command to
execute, not to be used as a parameter of an event.


You have several options, one is using a TCP/IP connection between the
service and your program, in this way you can transfer data back and
forth.
You could also use named pipes

You can even create an "event like" scenario using TCP/IP for the
service to notify your program. You can spawn a thread in your
program that listen to a given port (the port number used should had
been informed a priori to the service) when a connection is received a
connection is established and data exchanged, then your thread call
the handler in the UI thread to update the interface.

 

[Jesse Houwing]

Hello trant,

Thanks, I will look into that

Is it complicated?

If you have some knowlegde on webservices, then no...

Most books on WCF describe the most important steps in the first few chapters.
I can recommend
Addison Wesley - Essential Windows Communication Foundation (WCF) for .NET
Framework 3.5

 

[Paul]

I know this may seem like a good idea, but think for a minute.

The more complexity you add to the service results in the more likely it is
to actually break in the firstplace.

My suggestion would be to turn the service into a poller/scheduler and
remove all elements of business logic to a Business Logic Layer preferably
in Web Services so it runs in a different app domain. then get your
managment app to interogate an inteface layer on those webservices.

Services accessing DB's directly for error reporting is not a good idea as
9/10 its the DB thats caused an issue, so use MSMQ or Event viewer and
interegate these from your managment app, or add a web service layer for
fault reporting for apps. The Strategy/composite patterns are good for error
reporting.

e.g.

1 > try to call web service to report error > FAILED

2 > try to save Error to MSMQ > FALIED

3 > finally save error to Event viewer > SUCCESS

1 to 3 are concrete stategies and can be encapsulated in a composite that
will allow you to cycle through untill you succeed.