NServiceBus has a built in implementation of the Publish-subscribe pattern.
publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers. Instead, published messages are characterized into classes, without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are.
Or in simpler terms
Subscribers let the publisher know they're interested, and the publisher stores their addresses so that it knows where to send which message.
Depending on the features provided by a given transport there are two possible implementations of Publish-Subscribe mechanics: "Persistence based" and "Native".
Persistence based publish-subscribe is driven by subscribe and unsubscribe control messages sent by the subscriber to the publisher and relies on the publisher having access to a location to store the connection between message types and their subscribers.
Available subscription persistences include
Transports that require persistences
The subscribe workflow for persistence based transports is as follows
The publish workflow for persistence based transports is as follows
For transports that support publish–subscribe natively no persistence is required.
Transport that support native publish–subscribe
The subscribe workflow for native transports is as follows
Note that in this case the publisher does not interact in the subscribe workflow.
The publish workflow for native transports is as follows
In NServiceBus Version 3.0 and onwards subscriptions for types with the same Major version are considered compliant. This means that a subscription for MyEvent 1.1.0 will be considered valid for MyEvent 1.X.Y as well.
In some circumstances it may not be desirable to allow any endpoints to subscribe to a given publisher or event. NServiceBus provides a way to intervene in the subscription process and decide whether a given client should be allowed to subscribe to a given message.
The class implements the
IAuthorizeSubscriptions interface, which requires the
AuthorizeUnsubscribe methods. The implementation that comes in the sample doesn't do very much, returning true for both. In a real project, access some Access Control System, Active Directory, or maybe just a database to decide if the action should be allowed.
Last modified 2016-05-04 22:42:47Z