is NServiceBus useful in this WCF MVC scenario?

Question

I just started investigating nservicebus, and can't figure out of it's appropriate or maybe overkill for my particular situation. Architectural pointers are greatly appreciated, i'm struggling a bit.

I have an MVC website and WCF REST service that both receive messages, e.g. "post a question". This should trigger a number of actions, like storage of the enity, examiniation by a rules engine, and maybe sending a push message, updating some aggregate data. The result of the rules engine might also cause a new message to be created. These requirements may change in the future. I would like to implement this in a way where the receiving endpoint sends out a message to anyone who happens to be listening (person X created a new question).

I was thinking of storing the messages in a db table and having my modules monitor the table. This thought process was moved to msmq and then to pub sub using nservicebus. However, I'm not sure how this should be implemented.

I'm currently thinking about the following scenario. A question comes into the WCF REST service. The WCF service persists the question and publishes a new question message (so it would need to host nservicebus somehow?). My modules subscribed to the message take action, like send out a notification or trigger an action based on the defined rules.

Is this a scenario where pub sub using nservicebus will benefit me? And would this be the way to go about actually implmenting it?

Answer 1

The WCF service persists the question and publishes a new question message (so it would need to host nservicebus somehow?)

NServiceBus can be hosted in any managed process, including IIS. To do this (inside WCF service)

• Create an instance of IBus when your WCF service starts up.
• When you receive a question request into the service assemble your NServiceBus message
• Publish the messages by using IBus.Publish(MyMessage);

To create an instance of IBus in IIS a common method is to use the fluent configuration inside your global asmx. A typical configuration would look something like

public class Global : System.Web.HttpApplication
{
    public static IBus Bus { get; private set; }

    void Application_Start(object sender, EventArgs e)
    {
        Bus = NServiceBus.Configure.WithWeb()
            .Log4Net()
            .DefaultBuilder()
            .XmlSerializer()
            .MsmqTransport()
                .IsTransactional(false)
                .PurgeOnStartup(false)
            .UnicastBus()
                .ImpersonateSender(false)
            .CreateBus()
            .Start();
    } 

You define your NServiceBus endpoint (Queues) using the web.config:

<configSections>
    <section name="MsmqTransportConfig" 
             type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" />
</configSections>

<MsmqTransportConfig InputQueue="WebFrontEnd" 
                     ErrorQueue="error" 
                     NumberOfWorkerThreads="1" 
                     MaxRetries="5" />

My modules subscribed to the message take action

Your downstream subscribers can each be hosted inside the NServiceBus generic host running as a windows service, which is probably the easiest hosting option. The subscribers would each have a message handler class which implements IHandleMessages.

The way pub/sub works in NServiceBus:

1. A publisher service has an input queue and a subscription store.
2. A subscriber service has an input queue
3. The subscriber, on start-up will send a subscription message to the input queue of the publisher
4. The subscription message contains the type of message subscriber is interested in and the subscribers queue address
5. The publisher records the subscription in the subscription store.
6. The publisher receives a message.
7. The publisher evaluates the message type against the list of subscriptions
8. For each match found the publisher sends the message to the queue address.

You should probably download the NServiceBus pub-sub sample to gain a better understanding of this.

Answer 2

I think you would use NSB in place of WCF, not in addition to WCF. Service Buses introduce many new concepts and designs. the idea of asynchronous work is very different that traditional request/response.

To start, I would introduce a service bus until it's needed, that is until the request/response design becomes the bottleneck itself. A service bus isn't something you just "drop in" to an application. when introducing a service bus to an existing application you have to think through how eventually processing the command/event/message will impact the system which was designed using an imediate response & request.