I have a basic windows service which does some conversions of data. There's decoupled GUI which allows user to changes some configuration and this needs to be proprogated to the Windows Serivice running. Both of them are running the same box and implemented using C# .NET. Which is the best way to communicate to the service other than interprocess communication mechanisms like mutex, events etc.
Also I'd like to avoid to implement it as a web service because it's not a webservice.
I would use a WCF Service to communicate.
You can use netNamedPipe binding but that might not work on Windows 2008/Windows 7 since the Service runs in session 0 and all user code runs in sessions >0 and they would not be able to communicate.
So I used netTcpBinding in my own project.
If the processes are not going to move to different machines, you can use memory mapped files as the communication mechanism.
If that's not the case, WCF is a good option.
Since you're dealing with configuration data for the service, I would persist it somewhere. Database, file, registry, etc. UI writes the information and the service reads it when appropriate (e.g. each run).
Related
I'm currently evaluating the options for adding a web UI to a .NET 4.5 application that is installed and running as a Windows Service.
The basic idea is that the service application is running 24/7 and collects various data from network devices and persists them in a local data store (esentially, it monitors these devices)
The web UI interface is used for data presentation and analysis purposes and to send command & control messages to the backend (i.e. the service layer) which in turn fowards these commands to the network devices.
The big difference to a "classic" multi-tier web application is that the service part has to run even if no user has been interacting with it through the web UI (therefore the idea is to have it run as a Windows Service).
I currently do not know how to mix this web part (request/response pattern, short running) with the service part (polling on the network, long running, 24/7).
My ideas so far:
Embed IIS Core (or any other web server) into the service application: would probably work but the embedded web server would not know about any existing IIS configuration on the same machine which makes integration and configuration not straightforward (e.g. ports, authentication, SSL etc.)
Deploy an ASP.NET application on IIS and a separate service application: the ASP.NET application would then just act as a facade to the service and would need a proper and reliable way to communicate with the service application (two-way IPC?).
Currently it feels as if 2 is the best option.
If so, are there any IPC recommendations?
Thanks!
The simplest (and probably the worst) way is to embed all your logic to IIS and disable shutdown of your app (this way IIS app will run like a windows service).
I currently do not know how to mix this web part (request/response pattern, short running) with the service part (polling on the network, long running, 24/7).
You shouldn't. Regarding the second case I would suggest to decouple your service app and web ui app as much as possible. This way you minimize dependencies and IPC (therefore improve scalability and stability).
The windows service in this case may implement its minimal role: collecting various data from network devices and persists them in a local data store (the only feature that requires 24/7). IIS app may implement all UI-related features (data presentation and analysis roles) and user command. This way you don't need to delegate all presentation features to the windows service app. IPC is used just for sending command & control messages to the backend (i.e. the service layer) which in turn fowards these commands to the network devices.
I suggest using message queue model (ZeroMQ, MSMQ, RabbitMQ, etc) that is asynchronous IPC with its advantages. From the other hand it is possible to use the database itself for the IPC: e.g. push the messages to some table (or collection if using NoSQL) and read them by the win service app. This is an alternative to message queues but in most cases is worse than it.
The wording of the question doesn't necessarily do the issue justice...
I've got a client UI sitting on a local box with and a background windows service to support it while it performs background functions.
The client UI is just the presentation layer and the windows service does all the hard hitting action... so there needs to be communication between the two of them. After spending a while on google and reading best practices, I decided to make the service layer using WCF and named pipes.
The client UI is the WCF client and the windows service acts as the WCF host (hosting locally only) to support the client.
So this works fine, as it should. The client UI can pass data to the WCF host. But my question is, how do I make that data useful? I've got a couple engines running on the windows service/WCF host but the WCF host is completely unaware of the existence of any background engines. I need the client's communications requests to be able to interact with those engines.
Does anybody have any idea of a good design pattern or methodology on how to approach facilitating communication between a WCF host and running threads?
I think that your best bet is to have some static properties or methods that can be used to interchange data between the service threads/processes and the WCF service.
Alternatively, the way that we approach this is through the use of a database where the client or wcf service queues up requests for the service to respond to and the service, when it is available, updates the database with the responses to those requests. The client then polls the database (through WCF) on a regular basis to retrieve the results of any outstanding requests.
For example, if the client needs a report generated, we fire off a request through WCF and WCF creates a report generation request in the database.
The service responsible for generating reports regularly polls this table and, when it finds a new entry, it spins off a new thread/process that generates the report.
When the report has completed (either successfully or in failure), the service updates the database table with the result.
Meanwhile, the client asks the WCF service on a regular basis if any of the submitted reports have completed yet. The WCF service in turn polls the table for any requests that have been completed, but not been delivered to the client yet, gathers the information from them, and returns them to the client.
This mechanism allows us to do a couple of things:
1) We can scale the number of services processing these requests across multiple physical/virtual machines as the workload increases.
2) A given service can support numerous clients.
3) Through the WCF interface, we can extend this support to any client platform that we choose to support (web, win, tablet, phone, etc).
Forgot to mention:
Just because we elect to use a database doesn't mean that you have to in order to implement this pattern. You can easily implement the same functionality by creating a static request collection that the WCF service and worker service access in much the same way that we use the database.
You will just need to be very careful about properly obtaining and releasing locks on the static properties to avoid cross-thread collisions or deadlocks.
I am working on a project that i want to have a plugin-sandbox like System, However i am having issues working out 2-Way Real time Cross Process Communication. At first i thought of WCF, as it can pass object Metadata, but then soon realized that the Service Client model of WCF will pose an issue. but before i lay down all my ideas and questions here is what i have planned out.
I want to have a host application that will do most of the work, let us call this host.exe, host.exe will host the main application logic for the program, as well as the launching, executing, and killing of Plugins. Plugins will be hosted via a Plugin Proxy that will host them via MEF, so we will call it proxy.exe. The proxy.exe will load plugin dlls and host them in a secluded environment that will isolate faults and if the plugin fails it will kill the proxy and not the application. The Host and the Proxy need to communicate in real time in both directions and because there are going to be multiple proxy hosts it would be best to be able to pass object data.
so that is the basic idea of what i want. I was thinking of several ways to do this. the first being WCF, however i figured that the way WCF works it would be difficult if not impossible for the server of the service to send the client a request/command. the next idea what to use TCP, and have the host be a TCP server and develop a messaging protocol that i can use to communicate, however that poses an issue as i do not have the luxury of the WCF metadata and passing complex class information would be down right insane.
Through all my research i have came up with issue after issue after issue, it would much appreciated if anyone is able to suggest a solution to this issue. Thank you.
My solution for this would likely be remoting. I dont know if WCF does this the same way. but remoting can be configured with text and servers can be setup to remote to an object at will.
I want to warn you up front. The project I am mentioning is from quite a while ago so this may be out dated information (WCF may do the same thing or it may not, My company has not required any WCF work from me.)
I remoted my objects from the client to the server. I would run the server (actually on a separate machine) then using tcp remoting, all the objects I wanted would be declared into that application.
Now here is the fun part. that remoted object used non remoted delegate objects. I would initialize the object (remoted) and the server would create it. Then I would initialize another (Interface Typed) object local and attach it to the remote object.
When the remote object wanted to communicate to me it would send serializable information to me and I would construct that into more objects or commands. Whatever was needed... (possibly more remote objects)
In any rate. One server and multiple remote objects would be sent back and forth with a CommonInterface.dll with all the standard interface objects defined in it.
This was for all intents and purposes a blind plugin setup that any application wanting to get information to or from my server would be able to implement and handle their classes as long as the interfaces matched. (with serializable command data)
If the plugin (client) crashes then the application (server) would not have to suffer. It would just wrap all communication to that plugin in a try catch and the remoted object would have some sort of time to live or ping style release mechanism.
I dont really know what your scenario is going to be like with the sandboxing but this may accomplish what you are asking.
here is a .net remoting chat server.
http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx
This is the same type of project I build my first time with remoting. and I evolved it into my server plugin architecture. The difference between my use and yours is that the server was my client was the main application using the server and yours the server will be the main application allowing multiple clients to plugin.
In my opinion, I advice you use different application domains, an communicate with plug-ins using interfaces, and a real proxy object references. Do not use different processes, you can achieve plug-ins isolation through application domain isolation, because exceptions do not cross application domain boundaries unless specified.
As an alternative, you can use deprecated technologies, as .NET Remoting, for tje cusom marshaling and transparent proxy object creation.
In my opinion, WCF is too heavy and too far from real-time processing
Interprocess communication (IPC). Which maybe should called cross-process communication (CPC) is a known MS/Windows specific concept.
More about it here
In the past I've used RPC and Windows Pipes (which is used also in SQL server for transferring large data-sets/results)
You can always try another method of communication, WCF, Sockets, Pub/Sub Messaging; example, TibcoRv (which locally would bypass sockets).
I find these to be a bit of an overkill. but could be perfect for your requirement.
I have a timer in a windows service (.NET C#). I need to be able to change the elapsed value from an external program. If the timer is currently running, I need to be able to shorten the time elapsed value from an external program. I was thinking of having a public method in the service that would change the timer elapsed value and restart the timer, but can an external program call a public method on a windows service?
In short, it's not possible to directly call functions in another process. The process containing the function you want to access (in this case, your Windows service) will need to expose it through some sort of IPC (inter-process communication). What type of IPC you choose will probably depend on how complex the communication needs to be, and whether or not the "client" is a .NET application.
If your needs are simple (e.g. just setting a timer value), or if your client does not use .NET, using named pipes (or TCP, if you need to access the service from another physical machine) is probably your best bet. Both named pipes and TCP give you a Stream that you can write messages to and read on the other end.
If you need to expose many different functions or send and receive complex data types, and if you are using .NET on both ends, .NET Remoting or WCF is probably best. .NET Remoting is simpler but has more constraints; WCF is very flexible but has a steeper learning curve.
Yes this is possible.
You might want to consider created a NetNamedPipe endpoint on your service and controlling the service through that interface.
NetNamedPipeBinding binding = new NetNamedPipeBinding();
MyService myService = new MyService(binding,
new EndpointAddress("net.pipe://localhost/MyService"));
myService.ResetTimer(30);
You cannot call a method in a Windows service process directly, but you can have the Windows service expose this function as a WCF service, for instance. The Windows service would be acting as a service host as well. That's possible and not complicated.
Older (non WCF) services can use .NET Remoting. Have a look here for some info on how to get started. This is the pre-WCF way of communicating between applications across process boundaries.
I have an application that is built as a Windows Service and a c# library assembly (.dll.) In order to manage and maintain this service, I'd like to add the ability to run a command-line application that tells the last time the service archived files, the next time it's scheduled to do so, the status of the last run, and the location of a file created by the service.
What's the best architecture for writing a service and library that can share data with another application? I'm using .net 2.0.
The way that inter-process communication happens in .net is through remoting (even if both processes are on the same machine). Other responses have suggested alternatives to inter-process communication which would not require remoting.
The best architecture is probably to make your service be a "server" that can report on it's status (and whatever information you want). Using WCF for this like ocdecio suggested would make it pretty simple.
I use WCF for that and create a contract definition for the commands/events I want to support.
Options that spring to mind that I've applied in the past:
Save the information to a database
(if you have one to hand)
Implement a
"status monitor" type thread on the
service that the client can connect
to and query via TCP/IP etc.
A fairly simple approach is to store that information in either a local config / text file which both apps have access to. Or even to place it in a registry key.
+1 for just having the service provide that (and any other data) when it is queried (simple tcp, RPC, web service, or whatever)
I'd make it pretty generic - like
QueryInfo(some identifier)
with a response as some string and a return value or other indicator that the service does not know what you are talking about, cannot get the info, or give back the info