在Owin Startup类中使用OnMessage订阅Azure Service Bus

Question

I am working on a solution which will process messages from Azure Service Bus, my colleague suggested to use one of our existing Asp.Net WebApi App and subscribe to ASB in OWIN Startup eg

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // ... registering WebApi etc

        var queueClient = SubscriptionClient.CreateFromConnectionString("connection string", "sometopic", "somesubscription");

        queueClient.OnMessage(m =>
        {
            //do something with message

            m.Complete();
        }, new OnMessageOptions
        {
            AutoComplete = false,
            AutoRenewTimeout = TimeSpan.FromSeconds(30),
            MaxConcurrentCalls = 30
        });
    }
}

I personally think that this is not right way to do it and instead we should use WebJobs or WorkerRoles , hovewer I can't think of any arguments to convince him to my idea.

So the questions is:

1. Who is right, me or my colleague, or maybe both solutions are ok ?
2. In case if my colleague is not right what are the arguments against his solution ?

Answer 1

If that web api project does more than just listening to this queue consider these advantages of using the web job or worker role approach:

• Worker role can scale independently of the web app
• A web job / worker role can be updated independently of the web app
• Process isolation: if one fails the other might still run.

If you use Azure Functions ( https://azure.microsoft.com/en-us/services/functions/ ) you can even apply serverless computing. You pay only for the usage (not for the hosting of your function), and scales and can be updated independently as well.

Technically both approaches will work. If the processing of the messages has interaction with the web app directly (you did not tell what you do with the messages) it might make more sense to run it in the web app depending of the work.

A web site is better in handling requests instead of running a continuous process. A web job / worker role feels like a better environment for these kind of situations but also really take a look at Azure Functions.

Answer 2

One of the reasons that the Service Bus existed is to process this messages/queue in isolation as this particular process was identified to be a subsystem or subdomain of the bigger enterprise system. Therefore an app/service (in form of web worker roles/web jobs/azure functions) can be developed by same or different team that has focus domain knowledge of the subsystem. Since it is an independent process it can be scaled independently if the need requires it.

If the processing of the messages has dependency on the web app business logic/services, that can be a red flag as to why it needs to be in the Web API process.