Help with NServiceBus architecture

I've been reading through the documentation on the NServiceBus site but am struggling to piece it all together.

The goal is to provide a durable messaging solution between on-premise back office systems and a public facing web site in another data center.

I will need bidirectional (on-premi开发者_如何学JAVAse <> web site) pub-sub and request-response communication.

The documentation makes it clear that there isn't one central point that all communication goes through, but surely the subscriptions need to persisted somewhere (in a central location?).

The NServiceBus gateway does look like it would meet my requirements but I can't find any working examples of this.

Can someone provide a bit more detail on how the Gateway works and whether it will meet my requirements?

The subscriptions are persisted on each publisher endpoint. Say you have a service endpoint publishing web orders. All other services who are interested can subscribe by sending a subscription message to the publisher, who then stores the subscriptions locally. When a message is available the publisher evaluates the subscriptions and send a message to each of the subscribers.

This brings us onto your other requirement - that of request/response. Because NSB is based on msmq, everything is asynchronous. The most a publisher could do is send a response to a caller just saying that the request has been received and will be published. The nature of async messaging means that you cannot have a synchronous response from any downstream subscribers.

But this cost comes with benefits - namely reliability and availability.

Reliability - because you are using durable messaging the messages will eventually be delivered, at which point a response can be generated which will also eventually find it's way back to the caller. This is highly reliable when compared to request response.

Availability: because the publisher service is always able to send a message (whether a downstream subscriber is available or not), it never needs to block incoming requests. If you load balance your publisher somehow you can easily achieve availability at enterprise levels.

However you need to balance this against your latency requirements. Asynchrony usually equals latency. So if you have latency requirements in the sub-100 ms range NSB may not be your best bet.

Apologies for not answering your query about NSB Gateway - I have never used it.

Hope this helps.

The Gateway solves the communication problem between sites. It will ensure that messages get delivered from SiteA to SiteB. The messages are hashed and validated on the other end. Apparently there isn't an example of this in 2.5, so I'm thinking of throwing one together as this has come up a few times in the past month.