CODEWITHSUNDEEP
wcfarchitecturenservicebus
Russell Durham
Russell Durham

Reputation: 624

NServiceBus, WCF Architecture

So I'm looking into implementing NServiceBus in our current setup and just trying to get a better understanding of how things should be setup.

Our current setup consists of multiple clients (websites, scheduled tasks, etc..) calling a WCF service we have set up for handling the sending of emails. Of course, if the service goes down then our clients start getting errors and all of those messages are then lost (one of the reasons we want an ESB).

I've seen how you can configure your WCF service to handle nservicebus messages in a pub/sub setup. What I'm not sure on is what is the best way to set it up.

Setup 1:

Client (Publisher) -> NServiceBus handler (Subscriber) -> WCF Service

In this case, to scale you'd increase the number of handlers (hosted nservicebus services?), keeping just the one WCF service.

Setup 2:

Client (Publisher) -> WCF Service (Subscriber)

This one you just increase the number of WCF services to scale (updates would be a nightmare).

I just started looking into the ESB architecture in general so if I'm completely off let me know. I'm essentially just wanting to know what is working for you, and what the "best practice" tends to be.

Thanks!

Upvotes: 2

Views: 1325

Answers (2)

Phil Sandler
Phil Sandler

Reputation: 28046

I'm not completely clear on what you need WCF for anymore if you implement this via NServiceBus. Is the WCF component required for anything besides receiving messages (to send an email) from the multiple clients? If not, you could remove WCF from the equation.

From the sound of it, you will also want the Service to act as a single logical endpoint that handle requests to send emails. If that's the case, you will want to use Send (a command) instead of Publish (an event). Publish is used to broadcast an event, which means that something happened already; Send is used to instruct another component to do something. It sounds like you want the latter.

Scaling of an endpoint can be done via the Distributor. This may or may not be useful depending on where you expect the bottleneck to be.

Edit: Based on your comment, I would simply go with the second setup, and just add the handler to the WCF service. If you are hosting WCF in IIS, make sure you have something that wakes the process up if the app pool recycles (the incoming message won't wake it up the same way an incoming request to WCF will).

Upvotes: 1

Adam Fyles
Adam Fyles

Reputation: 6050

We do something similar internally where one NSB endpoint handles all the sending of email. The clients can either use NSB directly to Bus.Send() the command to send a message to the email endpoint or you can expose that endpoint via WCF as well (only to get the commands over to the endpoint). Once the endpoint has the commands, they would just call your existing service to maintain compatibility with your existing clients.

Upvotes: 0

Related Questions