You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature related to a problem? Please describe.
The NServiceBus.MessagingBridge provides the ability to bridge transports completely transparent to any endpoint. They are unaware their messages are being bridged and/or that there are endpoints listening on other transports.
In the initial version there is no way for the bridge to know if an endpoint
Message drive publish/subscribe
With message driven pub/sub, a subscriber actually sends a message to the publisher to let it know that it wants to subscribe. Theoretically the messaging bridge could pick those messages up and initiate a subscription, but since this is only used in MSMQ (which is dead) we decided not to go through the effort of implementing this.
Native publish/subscribe
With native pub/sub, a subscribing endpoint doesn't have to communicate using messages to the publisher. It just registers a subscription inside the centralized message broker. Whenever a message is published, either the message broker takes care of the publish or NServiceBus reads subscriptions and takes care of the publish.
As a result, in both cases the messaging bridge is unaware of registered subscriptions. With lots of subscribers, the configuration becomes a hassle. And every new subscriber means a change and redeploy of the messaging bridge host. This can be mitigated somewhat by hosting a bridge component together with each endpoint. As soon as the endpoint is migrated, that unique bridge component can be changed or removed. But it's far from ideal.
Describe the requested feature
The messaging bridge should be made aware of any existing subscriptions from endpoints, so that when the publisher is on the other side of the messaging bridge, it can register the subscription there as well.
Possible scenarios are:
All subscriptions are registered centrally in ServiceControl and it becomes a central hub for information. For itself, for the messaging bridge and possibly others as well.
NServiceBus provides an API to request subscriptions from brokers, endpoints or something else.
Describe the feature.
Is your feature related to a problem? Please describe.
The
NServiceBus.MessagingBridge
provides the ability to bridge transports completely transparent to any endpoint. They are unaware their messages are being bridged and/or that there are endpoints listening on other transports.In the initial version there is no way for the bridge to know if an endpoint
Message drive publish/subscribe
With message driven pub/sub, a subscriber actually sends a message to the publisher to let it know that it wants to subscribe. Theoretically the messaging bridge could pick those messages up and initiate a subscription, but since this is only used in MSMQ (which is dead) we decided not to go through the effort of implementing this.
Native publish/subscribe
With native pub/sub, a subscribing endpoint doesn't have to communicate using messages to the publisher. It just registers a subscription inside the centralized message broker. Whenever a message is published, either the message broker takes care of the publish or NServiceBus reads subscriptions and takes care of the publish.
As a result, in both cases the messaging bridge is unaware of registered subscriptions. With lots of subscribers, the configuration becomes a hassle. And every new subscriber means a change and redeploy of the messaging bridge host. This can be mitigated somewhat by hosting a bridge component together with each endpoint. As soon as the endpoint is migrated, that unique bridge component can be changed or removed. But it's far from ideal.
Describe the requested feature
The messaging bridge should be made aware of any existing subscriptions from endpoints, so that when the publisher is on the other side of the messaging bridge, it can register the subscription there as well.
Possible scenarios are:
Additional Context
The text was updated successfully, but these errors were encountered: