Table of Contents

Comparing JobFlow to NServiceBus/MassTransit

The main difference between JobFlow and NServiceBus is that NServiceBus could be viewed as primarily a communication/transmission method, which JobFlow is free use in place of any of the default transmission methods. To do so, implement a class with the interface IJobDispatcher.

[JobDispatcher(ConnectionType = "NServiceBus")]
public class NServiceBusDispatcher : IJobDispatcher
{
    public Task DispatchAsync(Job job, JObject jobData, IDocument document)
    {
        // ... ///

        return Task.CompletedTask;
    }
}

This implementation would allow JobFlow to dispatch jobs via NServiceBus messages.

The Manager attribute signals to the configuration classes that this is to be loaded in the dependency inject container as a transient service.

The job dispatch system within JobFlow finds dispatchers based on the Connection information (specifically the Type property on Connection) for a Job. For NServiceBus The JobDispatcher attribute allows the job dispatch system to find the appropriate dispatcher class.

Once completed, the JobFlow configuration in your Startup class can easily pick up on the new implementation:

serviceBuilder.AddJobFlow(c =>
{
    // Other configuration
    c.AddDependencyAssembly<NServiceBusDispatcher>();
}

NServiceBus Sagas

There is no reason JobFlow can't initiate NServiceBus sagas. For instance, if your project already has an ETL pipeline built out as a Saga, the JobFlow dispatcher can initiate that ETL process as long as the final step in the saga returns a result back to JobFlow. In that way, JobFlow can orchestrate multiple sagas as well as other cloud entities, especially since NServiceBus isn't designed to run on server-less cloud entities such as Azure Functions. For example, a flow could take the form of Saga A -> Azure Function X -> Saga B -> Azure Function Y.