Do I need a service bus for simple asynchronous command handling?

Question

My system uses The Command Pattern with separate handlers. My commands are executed on a CommandService which currently handles all commands in-process.

I have certain commands which do at least 1 of these things that are slow operations:

1. Sends an email
2. Generates a PDF
3. Sends a Fax
4. Interacts with 3rd party web services

I want all of these commands to be handled out of process so that the UI is more snappy.

Should I use a messaging bus just for these commands, or should I have the in-process command handler call BeginInvoke()?

Edit - Additional Info

The system has a small number of users (maybe 100 concurrent on a busy day), so the queue would likely never get very long. The main thing here is to reduce the amount of time the UI is blocked when sending an email with an attached PDF (the command in question). The employees have to execute that command many times in a day.

With the entire situation in mind, I think I'm going to go with BeginInvoke() for now for several reasons:

1. All the UI interactions would have to be touched to make sure that they behave as though the command succeeded. The reminder of "you need to send this document" is in multiple places in the UI and it does a full page refresh once the report is sent.
2. It's the middle of my client's busy season (they do over 50% of their yearly business in the summer), so it doesn't seem wise to me at this time to introduce a whole new piece of infrastructure that I'm unfamiliar with administering.

But knowing what I know now, on a new system I would use a service bus from the get-go for any slow commands (virtually every system needs to send an email) and design the UI so that commands could more easily be switched from synchronous to asynchronous processing. In implementation, that basically means every POST is AJAX and performs an action in the UI as if it succeeded. (For an example of this, check out how Facebook handles comments.)

Answer 1

Both solutions has their pros and cons.

• BeginInvoke is deadly simple solution and its semantic it is same as just calling a handler by command directly. But this solution depends on threading infrastructure: max thread numbers, frozen thread due to concurrent access to the IO resources etc.
• MessageBus is very flexible and powerful solution where you can control every aspect of commands handling process. But it introduces another abstraction layer to your application that would be an overengineering in case when simpler means better

I'd recommend to estimate your system loading requirements, number of these background tasks, growing factor etc and depends on that to make a decision.

But in my personal opinion introducing a bus solution fitting @ 80% of cases. You can introduce a naive bus implementation that will be possible to extend on the next iterations if needed.

Answer 2

It's probably more an issue of reliability that would push you towards a message bus. You see, if your original transaction (that which did the BeginInvoke) were to succeed, and then mid-way through your invocation the server were to crash, your system would have no memory that it still needs to send an email or generate the PDF.

A message bus would be able to roll-back that second transaction to a queue so that when the server started up again, it would go to send the email again.