Design of asynchronous component

Question

I'm trying to design an asynchronous component. Requirements on this component are :

• Component might receive events at any point in time
• Component might start a long-running operation and wait for its result. This operation is executed by outside system.
• Long running operation might be cancelled, either by the component or externally
• Events might come while long-running operation is running, which might start the long-running operation again, possibly cancelling previous invocation
• Components needs to decide what to do with event that comes during long-running operation, if to ignore it, queue it or something else
• Component might start different operations in reaction to different events
• Component can have multiple "backing values", where each has current value and its change request is an event component needs to react to
• It must be possible to unit test the component in isolation (this is important!)
• There will be multiple different components, some might share behaviors. For example ability to turn the component on/off.

So far I have tried/thought of:

• Reactive observables
  • This is what is used right now
  • I really like how testing can be done in virtual time
  • Long running operations are represented as function that transforms "request" observable into "response" observable
  • But it rest of the team considers this solution too complex
• Plain objects with methods for event handlers
  • Overall simple, but some constructions might be complex
  • Doesn't require additional libraries
  • Testing is not straightforward, as it is required to explicitly write every response to event instead of saying "for every request, respond in 5 ticks" like in reactive
• Tasks with async/await
  • I don't know how would it be possible to implement situation that happens when event happens during long-running operation and how to test this situation, which is why I choose reactive instead
• Actor framework (Akka)
  • This seems to be best fit for my requirements
  • But I don't like how testing is made, as it is using real time
  • And I believe Akka is way overkill for this use case, as we don't need per-component threading and the whole instrumentations to create actors and communicate between them
  • And I'm afraid my team would consider it too complex too

What I'm looking for are suggestions of possible other solutions, I might not have thought of. Or additional advantages/disadvantages of suggested solutions.

Answer 1

I think observable is the correct pattern.

Promise/Task/Future/Deferred with async/await is best suited when you have a single event (or branching logic chain of events) to follow. You will need a lot of additional work to make it fit your situation.

Most implementations of that use a generator*/IEnumerable/iterator under the covers anyway, with await becoming yield new Promise/yield return new Task and the calling coding being converted to an enumerator of promises/tasks.

Rx/observable is better suited where events can fire repeatedly and you want to treat them as a collection iterated over time.

You could roll your own class to handle this (possibly using async/await) but you'll have to solve a lot of the same problems that Rx already has while not saving on any complexity.

Answer 2

Your solution might be too complex because it's doing too much within itself. If, for example, you split long running task (AKA job) management into its own component, you can limit the interaction to managing those tasks. Similarly, the ad hoc event handling component might need to use the job manager, but limiting testing to those events can make it a bit easier to work with. I've taken that approach myself with a couple projects.

The way you handle the testing is by a couple well chosen interfaces. The implementation can be your Reactive observables, or a custom implementation, depending on your true needs. The IJob interface could look something like this:

public interface IJob
{
    string Id { get; }
    bool IsRunning { get; }
    Task Handle { get; }
    void Cancel();
    // and anything else you need.
}

You can also make a typed version to deal with Tasks that return a value.

The bottom line is that you might only need one of the long running task management components in your system. You can test all the interactions with this component easily, and you can test the component itself fairly easily. Since the Handle property exposes a Task you can easily have code that simply will await the job to finish.

I haven't worked with Reactive Observables, but you can provide a Task handle connected to a simple result fairly easily using a TaskCompletionSource. Inside the job you can either set the result or the error state when you need to explicitly, and outside code is none the wiser. The TaskCompletsionSource has a Task property that can be used for the Handle above.

You can have as many "ad hoc" components as you need, and as long as they have a consistent way of managing the long jobs, it should simplify the design into something that everybody can understand.