We have a current application that has consists of two solutions:
Windows Service
This one takes care of communication between devices (ie. IoT, and other devices through different communication protocols); this service also contains some logic and runs 24/7; writes ocassionally to a database (SQL or Influx).
Web Interface
The web interface shows some of the database information; but can also get information from the Windows Service (live data); we currently use RabbitMQ with RPC for this; but it is far from ideal. We use Typescript to call back to a controller; from the controller we RPC to the Windows Server and the way back again.
We are currently looking on how to evolve this to a more robust solution with less transfer objects in between while maintaining security as the web interface has login credentials.
Ideally we would replace all with SignalR as this would make the client side also easier; we have a lot of TypeScript currently to do Rx calls.
My particular concern would be security in having SignalR directly to the Windows Service.
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.
I'm trying to create a WCF service for our existing product.
The service should provide normal "webservice" features (one-way), but also act independently.
Sample scenario:
The client connects to the server
The server saves the client in a collection
Now I use an admin client / database entry to tell the client to do sth. (For example change config for log4net/NHibernate)
I've read some things about callbacks (mostly a chat system), but I'm still not sure if this will work.
Now my question is, will WCF be suitable for such a scenario or should I use TCPClient/TCPListener?
Currently I'm working on a design for a Windows Service application to fetch reports from an Oracle database, aggregate them to a message and send it to an external WCF SOAP service.
I would be grateful for some design suggestions concerning Windows services.
Should Windows Services use e.g. dedicated WAS/self-hosted WCF service (net.pipe/net.tcp) that provides data to achieve better separation / reusability?
So I would add a WCF service (net.pipe) that provides data (e.g. a GetReport method).
The Windows Service application would call GetReport and call the remote SOAP service to forward the aggregated message. The remote service and its client code are likely to change. It might be adapted for different customer projects.
If I understand correctly, your windows service will periodically fetch some data from the database and upload that data to a remote web service.
This means that your windows service is a client in terms of WCF communication and you won't need to implement any WCF server code inside it.
All you'll have to do is to connect to the remove web service and upload the data, e.g. using a client proxy generated for this remove service.
I don't think that it is required to add another WCF service that provides the data instead of querying the database directly as long as you don't have the requirement that another application will use the same WCF service. Until then I wouldn't add the service for the following reasons:
Another WCF service increases the complexity of the deployment and makes it harder to install and configure.
The connection to the new WCF service is another point that can break.
If you handle lots of data, getting them from the database directly is much more efficient instead of transferring them over a service protocol. As I understand your question, you aggregate the data in the windows service not in the database. Therefore you'd have to move the aggregation code to the new service also.
As said before, this recommendation will change once you have another potential client to the new service. In order to prepare for that, you should of course choose a design in your windows service that separates concerns well and is a good starting point to move some components later.
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
I want to control application (in my case it is corelDraw) ,I know I should use it's application object and I do this, but the issue now is I want to do this in webservice,
so as far as I understand if I put this code which control the application in the web-service ,my code will try to control the corel application which is on the server not on the client :(
so any hint/advice how could I do this, and control the application on the client not server ?!!!
As you already noticed web service runs on server and only result is passed to client.
Well you have a few options to control client machine over web service... Here is one of possible scenarios.
1. create web service that will provide commands for client
2. create windows service (client) that will consume your web service commands
3. inside windows service then just execute those commands in appropriate manner
Well I have to say this is not the prefered way I would take to automate corelDraw, but if you insist on using webservice as command provider it will do the job.
You need to ask yourself what is the difference between client and a server. Can a client be a server? Can a server be a client?
You make your client with CorelDraw installed to accept web-service request, i.e. effectively make it a web-service server, and then carry on as normal.
Although I would say web-service is not the best way to control such complex application as CorelDraw. I'd look in some other ways of communication between peers, like lower level network communication that would not have overhead of HTTP.