1

I am currently involved in a simple to medium complex IOT project. The main purpose of our application is gathering data from our devices and analyzing that data as well as calculating statistics.

On the server side we run a MVC application. Up until now we used Hangfire to schedule the calculations. Hangfire is an amazing tool for scheduling emails and other simple stuff, for more advanced things it's too slow. The calculations can take up a lot of time and are processor-intensive (we are trying to optimize them though), so we need to call them in a background task, a simple API call won't be enough.

I thought about splitting the application into multiple parts, the website, the core and a windows service.

The problem is, I never tried that before and I have no idea what the best practice is to achieve that kind of thing. I searched for examples and articles, but all I found were suggestions to use Hangfire and/or Quartz.NET.

Does anyone have any resources on what the best practice is to build a MVC application, a Windows service and how they could communicate (probably through a queue)? What is the best practice in such a situation?

Ziga Petek
  • 3,953
  • 5
  • 33
  • 43
  • You didn't mention yet why there is a need for (multiple) windows services. What do you want to achieve? Assumption: Retrieve the data via your site and do some calculation based upon the data in the backend services? – Jan Köhler Apr 23 '16 at 15:06
  • You are right, I forgot to mention that all our background tasks can take some time and we simply can not do all the work during an api call to the MVC application. I edited my answer appropriately – Ziga Petek Apr 23 '16 at 15:14
  • Ok, I've got still some questions ;) The devices just post the data and don't need any result of your calculations back, do they? So it's just a "fire and forget" action? Devices post data, site contacts service, service calculates and stores result somewhere? Then later on you or another process views/processes or whatever the calculated results? So the essence of my questions: is this some sort of oneway communication or does the result travel back the line? – Jan Köhler Apr 23 '16 at 15:24
  • Exactly. The devices post the data and don't need any response. The data from each device has to be processed, but that doesn't take long and we can do it during the POST call (although it would be good if we could do that in a background task too :) ). The more advanced calculations are for now done during the night in a background task, but we want to trigger them as soon as we reach a condition (like a specific amount of data being gathered or some specific data being sent to the server). The devices just need to send the data and know if the server got it (not processed it) – Ziga Petek Apr 23 '16 at 15:27

1 Answers1

1

Although there may be many different possible ways to connect a site with a windows service, I'd probably chose one of the following two, based on your statements:

Direct communication

One way of letting your site send data to your backend windows service would be to use WCF. The service would expose an endpoint. For simplicity's sake this could be a basicHttpBinding or a netTcpBinding. The choice should be made based on your specific requirements; if the data is small then basicHttp may be "sufficient".

The advantage of this approach is that there's relatively little overhead needed: You'll just have to setup the windows service (which you'll have to do anyway) and open a port for the WCF binding. The site acts as client, the service as server. There's nothing special with it, just because the client being a MVC site. You can take almost any WCF tutorial as a starting point.

Note that instead of WCF you could use another technology like .NET Remoting or even sockets just as well. Personally, I often use WCF because I'm quite used to it, but this choice is pretty opinion based.

Queued communication

If reliability and integrity is crucial for your project, then using a queue might be a good idea. Again: depending on your needs, there may come diffeent products into consideration. If you don't need much monitoring and out-of-the-box management goodies, then even a very simplistic technology like MSMQ may be sufficient.

If your demands to the aforementioned points are more relevant, then maybe you should look for something else. Just recently I got in touch with Service Bus for Windows Server (SBWS). It's the Azure Service Bus's little brother which can be used on premises locally on your windows server. The nice thing about it is, that it comes at no extra charge as it's already licensed with your windows server licence.

As with the first point: MSMQ and SBWS are just two examples. There may be a lot of other products like NServiceBus, ZeroMQ or others usable, you name it.

Jan Köhler
  • 5,817
  • 5
  • 26
  • 35
  • I was thinking of using mongoDB for the queue, since we already use it to store the data, but the service would have to access it every few seconds to see if there is new data and that could be overkill. MSMQ or SBWS would be a better option, thx for the info :) – Ziga Petek Apr 23 '16 at 16:50
  • SBWS seems promising to me, too. The ugly thing with it is only that it can be easily confused Azure Service Bus (ASB) as the resources seem to mix occasionally. You can use the [MSDN](https://msdn.microsoft.com/en-us/library/dn282144.aspx) as a first starting point. [This channel9 video](https://channel9.msdn.com/Blogs/Subscribe/Service-Bus-for-Windows-Server-11-Release) by [Clemens Vasters](http://stackoverflow.com/users/560396/clemens-vasters), who's very ambitioned in this field, is fine, too. – Jan Köhler Apr 23 '16 at 16:59