Can an ASP.NET application handle NServiceBus events?

Question

In most cases, if not all NSB examples for ASP.NET (or MVC) have a web application sending a message using Bus.Send and possibly registering for a simple callback, which is essentially how I use it in your application.

What interests me is if it is possible and / or it makes sense to process messages in one ASP.NET application.

The main reason I ask is caching. The process might look something like this:

• The user initiates the request from the web application.
• The web application sends a message to the stand-alone application server and registers the change in the local database.
• In future page requests from the same user, the web application finds out about this change and lists it in a pending state.
• A lot of things happen in focus, and ultimately requests are accepted or rejected. The event is published with reference to the original request.
• At this point, the web application should start displaying the latest information.

Now, in a real web application, I’m pretty sure that this pending request will be cached, possibly for a long period of time, because otherwise the application should query the database for pending changes every time the user requests current information.

Thus, when the request finally completes in the background, which may take a minute or a day, the web application needs, at a minimum, to invalidate this entry in the cache and perform another search in the database.

Now I understand that this can be controlled using SqlDependency objects, etc., but suppose they are unavailable - maybe this is not a SQL Server server, or maybe the request for current information falls into the service network, whatever. The question is, how does a web application know about a status change?

If you can handle NServiceBus messages in an ASP.NET application, what is the context of the handler? In other words, the IoC container will have to inject a bunch of dependencies, but how much are they? Is this all done in the context of an HTTP request? Or should everything be static / singleton for the message handler?

Is there a better / recommended approach to this problem?

Answer 1

I also wondered what is the appropriate level of connectivity for a web application with NServiceBus infrastructure? In my domain, I have a similar problem to solve the problem of using SignalR instead of cache. Like you, I did not find much documentation about this particular template. However, I think you can reason about some of the consequences of following it, and then decide if that makes sense in your environment.

In short, I would say that I believe it is entirely possible for a web application to subscribe to NServiceBus events. I do not think that there will be any technical obstacles, although I must admit that I have not really tried it - if you have time, be sure to do it. I just feel that if someone starts to do this, then probably a better overall design awaiting discovery. This is why I think this is so:

• The relevant question you need to ask relates to your cache implementation. If it's a distributed or centralized model (think SQL, MongoDB, Memcached, etc.), then the approach @Adam Fyles suggests sounds like a good idea. You will not need to notify each web application - a cache update can be performed by one NServiceBus endpoint, which is not part of your web application. In other words, each instance of your web application and the cache update endpoint will access the same shared cache. However, if your cache is in the process, such as Microsoft Web Cache, then, of course, you have to solve a much more complex task if you cannot rely on Eventual Consistency, as suggested.
• If your web application subscribes to a specific NServiceBus event, you will need to have a unique input queue for each instance of your web application. Since it is best practice to consider the scale of your web application using a load balancer, this means that you can end up with N queues and at least N subscriptions, which is more worrying than a constant number of subscriptions. Again, not a technical road block, just what will make me raise an eyebrow.
• The David Boike related article raises an interesting thought about application pools and how their lives can be uncertain. In addition, if you have several application pools running simultaneously for the same application on the server (common scenario), they will all try to read from the same message queue, and there is no good way to determine which one will actually process the message, More than not, it will make a difference. Sending commands, by contrast, does not require an input queue according to this Udi Dahan mail . This is why I think that one-way commands sent by web applications are much more common in practice.
• Here you can say a lot about the principle of shared responsibility. In general, I would say that if you can delegate as much as possible the "expertise" in sending and receiving messages to NServiceBus Host, your overall architecture will be cleaner and more manageable. From experience, I found that if I consider my web farm as a single entity, that is, I cancel all confirmations of the individual identifier of the web server, which I tend to worry less about. Each web server must be an endpoint on the bus, which means breaks, because now "which server" appears again as message queues.

Does this help clarify the situation?

Answer 2

An endpoint (NSB) can be created to subscribe to a published event and update the cache. The event should not be published until the actual update has been made so that you do not synchronize. The web application will continue to retrieve data from the cache on the next request, or you may create some kind of delay.