Re: Scheduled Services Architecture - Prototype - C# Discussion Boards

29-Mar-17 12:08

I was thinking about the design I posted here. So I decided to create a prototype. I welcome your thoughts.

Service Base Class

// Base class for all service classes
   public abstract class ServiceBase
   {
       public enum States
       {
           Cancelled,
           Processing,
           Stopped
       }

       #region Properties
       public States CurrentState { get; protected set; }

       public Guid ServiceId { get; private set; }

       public CancellationTokenSource CancellationTokenSource { get; private set; }
       #endregion

       #region CTOR
       public ServiceBase()
       {
           this.CurrentState = States.Stopped;
           this.ServiceId = Guid.NewGuid();
           this.CancellationTokenSource = new CancellationTokenSource();
       }
       #endregion

       #region Abstract Methods
       public abstract void Start();

       public abstract void Stop();
       #endregion

       #region Public Methods
       public void Cancel()
       {
           this.CurrentState = States.Cancelled;
           CancellationTokenSource.Cancel();
       }
       #endregion

       #region Private Methods
       protected bool CheckIfCancelled(bool throwIfCancelled = false)
       {
           bool cancelled = false;

           var token = CancellationTokenSource.Token;

           if (token.IsCancellationRequested)
           {
               cancelled = true;

               if (throwIfCancelled)
               {
                   token.ThrowIfCancellationRequested();
               }
           }

           return cancelled;
       }
       #endregion
   }

The goal is here to have this base class create and store its own CancellationTokenSource. Then, calling Cancel() on it would allow callers from outside to cancel it. Cancelling is to cancel the Task that it's running it, where Start() and Stop() control the service's procssing.

Service Implementation
Here's an implementation example of that class:

// Service class instance
public class MyService : ServiceBase
{
    #region Public Methods
    public override void Start()
    {
        // If the task has already been cancelled, then throw. This should never happen in my scenerio, but check anyway
        CheckIfCancelled(true);

        // Set the state to processing
        CurrentState = States.Processing;

        // Continue to do work as long as the task is not cancelled
        while (CurrentState == States.Processing)
        {
            if (CheckIfCancelled())
            {
                // Task has been cancelled, so break out of the loop
                break;
            }

            // Other code here
        }
    }

    public override void Stop()
    {
        // Stop processing, but don't cancel.
        CurrentState = States.Stopped;
    }
    #endregion
}

The purpose of this design is to wrap the Cancel code in the base class, so simple implementations like this only need a simple method call to figure out if it's been cancelled.

Usage
The, the Windows Service, which is hosting all the services, looks like this

private static List<ServiceBase> _services;
static void Main(string[] args)
{
    _services = new List<ServiceBase>();

<pre>
//Create a bunch service instances

for (int x = 0; x < 100; x++)
{
MyService service = new MyService(); // See the CTOR of ServiceBase
_services.Add(service);
}
// Start each service
foreach (var service in _services)
{
Task.Factory.StartNew(() =>
{
service.Start();

}, service.CancellationTokenSource.Token);
}
}

Notice that the Task.Factory.StartNew gets the Cancellation Token from the service class.

Stopping or Cancellign
Later on, when it comes time to stop processing, or to Cancel a task, I can do the following:

// LATER ON, WE CAN STOP OR CANCEL A SERVICE
private static ServiceBase GetServiceById(Guid serviceId)
{
    var service = _services.Where(x => x.ServiceId ==1 serviceId).FirstOrDefault();
    return service;
}

var s1 = GetServiceById(_services.FirstOrDefault().ServiceId);
s1.Stop();

var s2 = GetServiceById(_services.Last().ServiceId);
s1.Cancel();

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Bernhard Hiller29-Mar-17 21:41

Bernhard Hiller

29-Mar-17 21:41

Your Start method does not return. Use it to create the internal thread and start that thread.

private bool _keepRunning;
public void Start()
{
    _keepRunning = true;
    Thread thread = new Thread(MainFunction);
    thread.Start();
}
private void MainFunction()
{
    while(_keepRunning)
    {
        try
        {
            // your code here
        }
        catch(Exception ex)
        {
            // do something useful with the exception, e.g. log it, 
            // report it to the Windows Service, ...
        }
        Task.Delay(some time);
    }
}
public void Stop()
{
    _keepRunning = false;
}

You don't need a CancellationToken here; a CancellationToken is used for cancelling a thread in circumstances where you do not have other possibilities of stopping it; consequently, it must be available outside of the thread, too: it must be shared between the thread to be cancelled and the item requesting the cancellation.

Also, you can now start your services in a "common" for/foreach loop.

Kevin Marois30-Mar-17 4:30

30-Mar-17 4:30

Thanks for your input. Interesting approach.

I guess I was thinking that I wanted the Windows Service to create the threads. I'm trying to make this design so that other developers don't have to worry about the threading. They will only need to code up the Start() method with the services' code and leave the threading portion to the Windows Service.

As far as cancelling goes... I'm trying to make a clear distinction between cancelling a thread for the purpose of uninstalling a service, and stopping it which really means "pause" its processing.

These services will be loaded and launched via a scheduler process, so that's why I put the start portion in the Windows Service and included the CancellationToken.

Bernhard Hiller wrote:
it must be shared between the thread to be cancelled and the item requesting the cancellation.

Note that the token is retrieved off the Service itself

// Start each service
foreach (var service in _services)
{
    Task.Factory.StartNew(() =>
    {
        service.Start();

    }, service.CancellationTokenSource.Token);  //<== Token from the service class
}

So, while I like your idea, is there any reason that you can see why my design wouldn't work?

Thanks

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Nathan Minier30-Mar-17 1:30

Nathan Minier

30-Mar-17 1:30

You've been putting a lot of work into this, and I'm glad to see that you have a product gelling.

I have to agree with Bernhard on his point about external tokens as a control measure.

I have also have gone down this road, and I've found that having some event hooks for individual component recycling and monitoring go a long way to making this sort of host service work more effectively.

"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli

Pete O'Hanlon3-Apr-17 2:26

Pete O'Hanlon

3-Apr-17 2:26

Something I would consider, if I were you, is some form of heartbeat capability. Basically, you would use the heartbeat to determine whether or not a service is alive.

This space for rent

Kevin Marois3-Apr-17 5:38

Re: Visual Studio 2017 Defective Editor in Design Mode

3-Apr-17 5:38

By heartbeat I assume you mean some kind of ping from the server into the client?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Visual C# Frameworks

zequion28-Mar-17 20:43

zequion

28-Mar-17 20:43

I also wanted to ask what are the best frameworks to improve the appearance of buttons. Microsoft has made no effort in this regard. I use DevComponents DotNetBar but it seems that few people use it and wanted to know what you are using.

modified 29-Mar-17 7:19am.

Eddy Vluggen28-Mar-17 22:54

Eddy Vluggen

28-Mar-17 22:54

Regequion wrote:
Microsoft has made no effort in this regard.

I prefer plain WinForms, because of the effort they have made.

It is a very recognizable button, and it will look like that uniformly across all applications. There is no guessing involved for the user on what the control would do or how to use it.

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Re: Visual C# Frameworks

Kevin Marois29-Mar-17 4:18

Scheduled Services Architecture

29-Mar-17 4:18

Have you looked at WPF? With WPF you can do anything you want to any element, so you can create the look and feel you need with very little work.

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Kevin Marois28-Mar-17 7:53

Re: Scheduled Services Architecture

28-Mar-17 7:53

This is a bit long but I really need some validation on my project. I would appreciate your thoughts on the overall design and also my questions at the end

Overview
I'm creating an app that will run individual assemblies (called "Services") in a Windows Service. The Windows Service will really just be a host for the service classes that can be run according to a schedule. A "Service" is just an an assembly that implements an interface. Its run duration is determined by a schedule. It can run one time, or repeatedly according to scheduling options.

The Windows Service will be running on remote instruments around the world. The Windows Service will listen to a SignalR service running on our server that will all us to install, start, stop, disable, remove, or change the schedule for any or all of the "Services" on a particular instrument.

An example of a use case is diagnostics. A service will execute every 5 minutes to query a local DB for error records, then report its findings back to our server. The will be other use cases as well.

Details
On startup of the Windows Service the app will load services from a 'manifest'. This file is just a serialized list of services to load and when to run them. If an assembly is not runable (because the schedule says not to run, or it's been disabled), the it's not loaded.

Here's the manifest, not including the scheduling details.

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfService xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Service>
    <ServiceName>TestClass1</ServiceName>
    <ServiceId>59182d7e-8874-4d40-bdba-44936bcce815</ServiceId>
    <AssemblyName>Services.Test.dll</AssemblyName>
    <State>Ready</State>
  </Service>
</ArrayOfService>

Assemblies that can be run will implement this interface

public interface IService
{
    event EventHandler<ServiceMessageModel> StatusChanged;

    string ServiceName { get; set; }

    Guid ServiceId { get; set; }

    ServiceState State { get; set; }

    void Start();

    void Stop();
}

For each item in the manifest the app will create an instance of each class and store that reference in a list:

private void LoadServices()
{
    _services = new List<IService>();

    string[] files = Directory.GetFiles(_servicesLocation, "*.dll");

    foreach (string file in files)
    {
        var assemblyExistsInManifest = _manifest.Where(x => file.Contains(x.AssemblyName)).Any();
        if (assemblyExistsInManifest)
        {
            Assembly assembly = Assembly.LoadFrom(file);
            var types = assembly.GetTypes();

            foreach (Type type in types)
            {
                var typeExistsInManifest = _manifest.Where(x => type.ToString().Contains(x.ServiceName)).Any();

                var implementsInterface = typeof(IService).IsAssignableFrom(type);

                if (typeExistsInManifest && implementsInterface)

                    var serviceClass = Activator.CreateInstance(type) as IService;
                    serviceClass.StatusChanged += ServiceClass_StatusChanged;

                    _services.Add(serviceClass);
                }
            }
        }
    }
}

Next, the list is iterated and each service in it is started in its own thread

private void StartAllServices()
{
    foreach (var service in _services)
    {
        Task.Factory.StartNew(() =>
        {
            service.Start();

        });
    }
}

This is the basic idea and some code that I already have in place.

Questions
1) Cancelling / Pausing. I need to be able to stop a service from further processing. This could mean the service remains loaded but does not continue processing, or it could mean actually cancelling the task the service is running is so it can be unloaded.

This means that I would need to store separate CancellationTokenSource instances for each service as they're loaded in the StartService method above so that I can call Cancel() on a task for a specific service. If I defined the CancellationTokenSource as a property on the IService interface, then the StartServices method could create the CancellationTokenSource and assign it to the service at the time it is started.

This would allow my CancelService method to look like this

private void CancelService(Guid serviceId)
{
    // Find the service class for the speified Id
    var service = _services.FirstOrDefault(x => x.ServiceId == serviceId);

    // If it was found...
    if (service != null)
    {
        // Cancel the task
        var ct = service.CancellationToken; // Get the token off the service.
        ct.Cancel();
    }
}

Any thoughts on this?

2) Error Handling. Assuming an exception happens inside a service, this should not "crash" the service but instead set its State to Error and report that to the Host running on our server. The Windows Service portion should catch exceptions thrown by the services and report that back to the server. At no point should an exception cause either the Windows Service or any service to stop running. Any thoughts on this?

Summary
I'm VERY new to TPL and have little to no experience with it, so this design may be totally wrong. If so, please share your thoughts on a more stable approach. I would also appreciate any example code you may have.

Thank you

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

modified 28-Mar-17 14:42pm.

Bernhard Hiller28-Mar-17 21:13

Bernhard Hiller

28-Mar-17 21:13

Starting the services: I'd prefer to have some kind of thread owned by a class implementing IService. In its Start method, that thread is created and started. Use a try...catch inside the loop of the main method (or in the Timer_Elapsed event, if you use a timer). Start/Stop can be controlled with a boolean member variable _keepRunning - just check it in the loop.
Error Handling: Add an "error event" to IService which gets subscribed by the Windows service. Ideally, it contains some information about how corrupted the state of that service is, such that the main service can decide if it's appropriate to unload it and create a new instance.

Re: Scheduled Services Architecture

Kevin Marois29-Mar-17 4:15

Re: Scheduled Services Architecture

29-Mar-17 4:15

If I understand what you're saying.. it would mean creating the thread and error handling INSIDE the service classes, correct?

If so, it puts the responsibility on individual developers to follow the pattern to make it work.

Classes implementing IService only really need to have some basic info (Id, Name) and Start and Stop methods that the Windows Service can call into.

Am I understanding what you're saying here?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Kevin Marois29-Mar-17 4:19

Handle Exception In Thread

29-Mar-17 4:19

Can you provide a small example to illustrate what you're saying here?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Kevin Marois27-Mar-17 9:35

27-Mar-17 9:35

I'm creating a class instance using Activator.CreateInstance

var serviceClass = Activator.CreateInstance(type) as IInstrumentService;
_services.Add(serviceClass);

Then, later, I start each service. I want to catch any exceptions that occur in the service class. I was thinking about something like

private void StartAllServices()
{
    foreach (var service in _services)
    {
        Task.Factory.StartNew(() =>
        {
            service.Start();

        }).ContinueWith(task =>
        {
            if (task.Exception != null)
            {
                // Handle the exception here
            }
        });
    }
}

Any reason this would not work? Know of a better way to do this?

Thanks

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Rob Philpott28-Mar-17 0:01

Rob Philpott

28-Mar-17 0:01

Hi Kevin,

So does your service have a Stop() method as well? Normally a start method would be kind of asynchronous in nature, kicking off its own threads, opening network listeners and that sort of thing, so the test you have there looks like it would catch exceptions in just that part.

Or is it that Start() method is more of a Run()? By which I means it runs until completion, possibly days later?

A good catch all would be this (lifted from Visual Studio right in front of me):

// catch any unhandled exceptions
AppDomain.CurrentDomain.UnhandledException += CurrentDomainUnhandledException;

Regards,
Rob Philpott.

Kevin Marois28-Mar-17 5:55

28-Mar-17 5:55

Yes, the services have a Stop method. The services are independent of each other. They can each do entirely different things.

There will be a schedule in place that each services runs under. One may run only once, while another may run regularly at different days & times.

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Nathan Minier28-Mar-17 1:35

Nathan Minier

28-Mar-17 1:35

Just a quick note:

Passing a cancellation token to the Task.Factory.StartNew() will give you an external control for your child tasks.

Otherwise I've been playing with the same construct for a component host (except that I hydrate my components via a MEF ImportMany) and it works very well.

"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli