It is easy to display the status of a Windows service or to control it (start/stop) from a GUI application but the question if how about receiving/sending notifications from the service? Like: service telling to the user monitoring it that it needs attention.
Please consider that you can have several controllers started at any time in a multi-user environment.
Do you know an example(open source) for this kind of communication?
Extra points for a platform independent solution :)
If the "user" monitoring the service is a person, how about writing to an event log and then having your enterprise event monitoring system send alerts. Alternatively, have the service log the issue to the event log and then send an email.
If the "user" or client of the service is a separate or multiple applications here are a couple thoughts without fully understadning your problem.
Write to file. Have the client tell the service what file or some agreed token to create a file for that particular client instance and then have the service write to the file. The client can then monitor the file.
Status Ping. Have the client ping the service on a regular basis in a background thread to ask the service how it is doing. If unhealthy, then the client could ping the service for more information. Kind of like getting the LastMessage.
Open Sockets or End Point. Find a way to setup communication back from the service so that the service can call the client. This may be initiated by the client first telling the service where it is so it can call back. I forget the specifics, but WCF should be able to handle this out of the box for you. If you want something more generic you may need to roll your own.
Hope these ideas help.
As an option, use our MsgConnect (free with source) to send messages between services and controllers (crossplatform). Communication between services and controllers is possible both locally (via MMF or socket transport) and remotely (via socket transport).
Related
My question is, is there a good way to push an integer value to a running windows service without restarting it and without writing to disk or having it poll some database?
Here's my scenario and a few thoughts:
I need to pass data to a windows service in real time I DO NOT want there to be a delay. All I need to give it is in integer and it can do the rest. My predecessor had it set up to poll a database every 10 min but that is no longer an option. I need the response time to be less than a second. I suppose technically I could just reduce the poll time to 0.5 sec but I'm thinking that would be bad for the database server. I know you can pass data to a windows service when it starts but restarting this service isn't an option because of what it's doing.
I would love to use a web service and just call a web method to pass in the data but the tasks require elevated (admin) permissions and almost everything involves file system access so my understanding is that a web service isn't really the best option either.
I've thought of using a hybrid scenario where I run a web service and a windows service on the same machine but then I still have the problem of how to pass the integer from the web service to the windows service... I could technically use a file system watcher but I really don't want to create a file just to pass an integer. I thought maybe I could use localDb and have the web service just write the value there and have the windows service poll localDb every 0.5 sec, But I'm not sure how much that polling would affect overall performance of other things. I really want a way to push data to the windows service rather than having the service poll somewhere else.
The project I work on has a front-end UI that communicates with a Windows Service running on the same system. In the past, I used the Windows Communication Foundation (WCF), but found this to be heavy-weight for what I really needed. I am now using a TCP socket over the localhost address (127.0.0.1) to exchange data between the UI and the service.
Based on your description, the web service approach seems heavy-weight, kinda like the WCF approach we used to use. And, as you've noted, it has permissions issues. A simple application that pushes the integer to your service over a socket would be straightforward in my mind.
If WCF is of interest, here's a couple links that might help:
Creating a user interface for monitoring and interacting with a running windows service
GUI and windows service communication
Background:
I've a local application that process the user input for 3 second (approximately) and then return an answer (output) to the user.
(I don't want to go into details about my application in purpose of not complicate the question and keep it a pure architectural question)
My Goal:
I want to make my application a service in the cloud and expose API
(for the upcoming website and for clients that will connect the service without install the software locally)
Possible Solutions:
Deploy WCF on the cloud and use my application there, so clients can invoke the service and use my application on the cloud. (RPC style)
Use a Web-API that will insert the request into queue and then a worker role will dequeue requests and post the results to a DB, so the client will send one request for creating a request in the queue, and another request for getting the result (which the Web-API will get from the DB).
The Problems:
If I go with the WCF solution (#1) I cant handle great loads of requests, maybe 10-20 simultaneously.
If I go with the WebAPI-Queue-WorkerRole solution (#2) sometimes the client will need to request the results multiple times its can be a problem.
If I go with the WebAPI-Queue-WorkerRole solution (#2) the process isn't sync, the client will not get the result once the process of his request is done, he need to request the result.
Questions:
In the WebAPI-Queue-WorkerRole solution (#2), can I somehow alert the client once his request has processed and done ? so I can save the client multiple request (for the result).
Asking multiple times for the result isn't old stuff ? I remmemeber that 10 - 15 years ago its was accepted but now ? I know that VirusTotal API use this kind of design.
There is a better solution ? one that will handle great loads and will be sync or async (returning result to the client once it done) ?
Thank you.
If you're using Azure, why not simply fire up more servers and use load balancing to handle more load? In that way, as your load increases, you have more servers to handle the requests.
Microsoft recently made available the Azure Service Fabric, which gives you a lot of control over spinning up and shutting down these services.
I am working on oracle SOA, I created a asynchrous connection and I was able to get the message that I was successful. Now as a client, how can I check if my service is working correctly. I am a newbie, any help would be appreciated.
As a client you don't. you can't, know the service is working. That is the, um, magic of SOA. You submit your request and just have to trust that the service will keep its side of the contact.
So, this service does something. Eventually. There must be some tangible output - an order placed, a password reset, a report generated. At that point the service should communicate the outcome to the client by some mechanism depending on the nature of your application and the service in question - probably email or SMS, but perhaps a record in a table or a generated web page.
This it really a design or architectural question. A Service is a process: there's a triggering action - the client's submission - and an outcome, which is what the client wants (or an exception). In between is a set of business sub-routines which are largely invisible to the client (although a long running service might have windows, like Amazon's order tracking service).
You need to design your service so that it communicates the outcome to the client in some fashion. The precise details will obviously depend on what your service does.
I was wondering, what is the best way to do the following using C++/WinAPIs on a Windows system?
I have a local service application along with running client applications (that run on each logged on user session account.) The service application needs to notify all client applications to perform a one time operation (say, read data from registry and process it.) How do you implement this mechanism of notifying all client apps of a one-time event?
Service could send a broadcast windows message for which all client apps would listen. Of course, client apps need to have a message loop. Have you looked at SendNotifyMessage function?
You could use an event with a particular name that all the apps agree on. Then reset it after a period of time.
I have a service which constantly checks some application and assures that it wasn't closed. If this app closed - service launches it again.
The problem starts when user decides to log off the session. During logoff all applications are closing including the mine one. But the service is still running and constantly trying to start it again.
The questions is how to notify the service that user is going to log off and the application doesn't need to be restarted anymore? I've tried to make it using SERVICE_CONTROL_SESSIONCHANGE notification. But in accordance to MSDN they come to services when all apps already closed and logging off procedure completed. It is too late for me. Is there any way to programmatically find out that current session is in process of logging off?
My service launched under LocalSystem account.
Thanks.
p.s. I don't have the access to application source code. The goal need to be achieved without modifying it.
Have your service run two applications: the one it is a watchdog for, and a second one which you implement yourself. This second one can then respond to the log-off event by sending a message to the service (a la David Heffernan's answer), and the service will then know not to restart the watched job.
Open a communication channel between your app and your service and arrange for the app to tell the service that it is closing because of a logoff event.
You may not have access to the source code of the executable, but that doesn't mean that you can't affect the process. For instance, you could inject a DLL. Using SetWindowsHookEx, you'd catch the WM_ENDSESSION sent to the apps main window.
Why don't you create your service under the user that is running the App and tell it to startup automatic? In this case you should get the SERVICE_CONTROL_SHUTDOWN message when your user is logging off since the service would also be terminated.