A few weeks back I asked a similar question on SO. In a nut shell, my approach for some time now has been to develop a Windows Service. I would use NServiceBus (essentially MSMQ under the covers) to marshal requests from my web app to my service. I used to use WCF but getting a distributed transaction to work correctly over WCF always seemed like a pain in the ass. NServiceBus did the trick, I could commit data and create tasks in a transaction and not worry whether my service was up and running at the time. As a simple example, if ever I needed to send an email (for example a registration email) I would create the user account and fire off a signal to my Windows Service (to send the email) in a transaction. The message handler on the service side would pick up the message and process accordingly.
Since ASP .NET 4.0 and AppFabric have been released, there are a number of viable alternatives to the mechanism above. Referring back to the question I mentioned above, we now have AppFabric's AppInitialize(via net.pipe) as well as ASP .NET 4.0's Auto-Start feature which make developing Windows Services as web apps a viable alternative. I have started doing this now for a number of reasons (biggest one being deployment is no longer a pain in the ass):
- You can develop a web UI over your service (since it's running as a web app). This is extremely useful to see what is happening at runtime.
- Your deployment model for your web apps will work for your service application.
- IIS provides a few neat features for handling application failures (similar in some respects to a Windows Service).
- Web developers are very familiar with developing web apps (naturally), most don't know much about best practice when developing a Windows Service.
- It provides a number of alternatives to exposing an API for other apps to consume.
If you go this route (forgive me for copying and pasting from my original post) I would definitely consider running the background logic in a separate web application. There are number of reasons for this:
- Security. There may be a different security model for the UI displaying information about the running background processes. I would not want to expose this UI to anyone else but the ops team. Also, the web application may run as a different user which has an elevated set of permissions.
- Maintenance. It would be great to be able to deploy changes to the application hosting the background processes without impacting on user's using the front end website.
- Performance. Having the application separated from the main site processing user requests means that background threads will not diminish IIS's capability to handle the incoming request queue. Furthermore, the application processing the background tasks could be deployed to a separate server if required.
Doing this gets back to the marshaling aspect. WCF, NServiceBus/RabbitMQ/ActiveMQ etc., vanilla MSMQ, RESTful API (think MVC) are all options. If you are using Windows Workflow 4.0 you could expose a host endpoint which your web app could consume.
The web hosting approach for services is still fairly new to me, only time will tell if it was the correct choice. So far so good though. By the way, if you don't want to use AppFabric (I couldn't because for some bizarre reason, Windows Server Web Edition ain't supported), the Auto-Start capability mentioned in the Gu's post works nicely. Stay away from the applicationhost.config file though, everything in that post is possible to setup through the IIS console (Configuration Editor on the main server level).
Note: I had originally posted a few more links in this message but alas, this is my first post to this exchange and only one link is supported! There was basically two others, to get them Google "Death to Windows Services...Long Live AppFabric!" and "auto-start-asp-net-applications". Sorry about that.
To my knowledge, the only standard for specific technologies is "whatever works for your needs."
That said, you might want to look into Redis. I've used it before to communicate between disparate systems, and it works well.
Basically, what it is is an in-memory datastore. You set the service to watch for a specific key, and when your system does something with that watched key, the service reacts.
In a more general sense, what you're asking for is often known as a "pub-sub" (publisher-subscriber) setup. So if Redis doesn't work for you, you might be able to use the more general term to find a solution that does work. And really, if you wanted to, you could leverage Twitter to be the intermediary, if you really wanted to (the system would post a tweet, and the service would watch the twitter feed for updates). If I recall correctly, GitHub uses Hubot and Campfire in a similar manner (Hubot sits in a Campfire chat room, waiting for someone to send commands, to which Hubot responds).
Best Answer
If you are using flowcharts, then you can have 3 separate flowcharts. 1 to represent the overall view showing the decision that leads to initiating the service in the 2 different ways you say you have in your case. The other two diagrams will detail the process in each scenario. Flow charting is a loose technique with hardly any rules beyond what the shapes mean. This causes an inconsistency problem sometimes.
For documenting OO systems, I suggest you use UML 2.0+ and in particular Activity diagrams (similar to flow charts) and Sequence diagrams as well as use cases.