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.