The problem here is that writing your own integration is a much more involved undertaking than it might first appear. In this context, do MassTransit nor nServiceBus offer much beyond an abstraction layer for commands and events? It’s always a good idea to separate the underlying transport to make it easier to mock or replace, but does this warrant adopting a large framework? Why not just write your own light abstraction? They don’t come with the sophisticated tooling offered by nServiceBus, but they can provide a simple messaging fabric if you’re prepared to do some manual leg-work to connect things up.
These days we have a host of broker-based messahing solutions available to us such as RabbitMQ, ActiveMQ and Azure Service Bus. As a commercially supported product nServiceBus also built out a range of extra features to include modelling tools and advanced monitoring facilities. there was nothing to support event-based integration. They put a framework on top of Microsoft’s default messaging transport ( MSMQ) to add features such as publish\subscribe and transactional messaging (i.e. MassTransit and nServiceBus were both developed nearly ten years ago to plug a gap in Microsoft’s integration landscape, i.e. They also provide support for tracking long-running transactions.ĭespite this, both platforms may look increasingly out of place in a future that is likely to be dominated by more diverse technologies and autonomous agile development teams. They abstract the underlying transport away from collaborating applications and handle features such as retries and poisoned messages. They implement asynchronous messaging patterns such as publish\subscribe. They both provide a consistent messaging abstraction based on events and commands. Both nServiceBus and MassTransit address a similar set of integration problems and there are a lot of similarities between them.
0 kommentar(er)
