This is a guide for migrating from the
NService. community package to Particular Software's
One important difference between
NServiceBus. is that the
NServiceBus. is supported by Particular Software.
NServiceBus. is a community package and is not supported by Particular Software.
The bridge does not require what the NServiceBus.Router calls connectors.
NServiceBus.Router has the concept of connectors which it uses to configure endpoints so that messages are delivered to the correct destination. Connectors must be deployed alongside the endpoints they are routing. The bridge does not require connectors or any other similar component. Endpoints are not aware that a bridge is translating messages between transports so after migrating to the bridge, these connectors no longer need to be deployed with each endpoint. One of the benefits of this is that migration to a different transport becomes easier than with the NServiceBus.Router.
To migrate the following messages must be taken into consideration:
- In-flight messages
- Additional messages
In-flight messages are messages that were sent to an endpoint but have not been processed yet. That is, a message may have been sent using NServiceBus.Router but after migration, it may be processed by the transport bridge. Since the NServiceBus.Router changes the routing for messages so that they are sent directly to the Router component, this means that any in-flight messages will require the Router to be available to them, even when endpoints have already been configured to no longer use the Router anymore.
Because of this, the NServiceBus.Router must remain running until all in-flight messages have been delivered. The time this takes is specific to each system. If it is unclear what the right time is to stop the NServiceBus.Router, contact Particular Software for guidance.
Commands are the easiest to migrate as they have a specific route to a specific logical endpoint. After the transport bridge has been set up and running, every endpoint can remove any NServiceBus.Router-related configuration for routing commands using the connector. This implies that the original routing towards the specific endpoint can be restored and the bridge will make sure it is transferred to the correct transport.
Events require more effort to migrate to the transport bridge from NServiceBus.Router. The issue is with the subscriptions that are registered within a message broker. The scenario could exist as seen in the graph below, where
Endpoint B publishes an event and the event is sent to both the
NServiceBus. and the
NServiceBus.. As a result,
Endpoint C could receive the same event twice.
Note that both events would have the same message identifier, which allows the outbox to de-duplicate the messages. Without the outbox, either the message handler must be idempotent or the event will be processed twice.
For this scenario, take the following steps to move from NServiceBus.Router to NServiceBus.Transport.Bridge:
- Stop both
- Configure the
Bridgeto register a publisher with
Endpoint Cfor the event that
- Remove the subscription from the message broker for the
- Add the subscription to the message broker for the
- Start the
Bridge starts up, it will also create the subscription; it is not required to manually create the subscription in the message broker. However, be aware of when
Endpoint B cannot be taken offline due to high availability, scaling out or service level agreements.
There may be additional messages, like request/response messages, which route a message back to the endpoint it originated from. These must be routed back using the NServiceBus.Router component. The result is that as long as there are messages like these to be processed, the NServiceBus.Router component must be active within the system alongside the bridge.
Migrating from NServiceBus.Router to NServiceBus.Transport.Bridge is not difficult, but it requires careful consideration and analysis before the NServiceBus.Router component can be completely removed from a system.