I'm creating a Windows desktop application (not using WPF) and I'd like to make async server calls from client with tracking capability. Let me explain using an example:
I have a few service classes (inherited from CommandBase) in which I initiate a long-running tasks. Each service is dedicated to certain server-side functionalities of the application.
I need these services to start their task on server side (delegate it to another thread on the server) and come back quickly. Then whenever is requested by the client, these services can go back to the server and find out about the progress of the task.
I know for the fact that server side code is stateless. But is there any solution that I can add to CSLA's implementation to gain such capability? Is "Message Queue" my only solution?
I've also seen suggestion about using BackgroundWorker. But I can't use that. Cause it initiates the processing from the client side. I want this to be as loosely coupled with client as possible.
Can u be more specific?
As i understand u want to know the current state of a long running task running at a server (might be load balancing so u don't know which one). U have to save states to a shared location, a database would be best to use imho.
The simplest way is:
- Keep state at the server;
- Let the client poll at a regular interval.
If I understand you correctly, this isn't really a CSLA question as much as a "how do I implement long-running tasks on a Windows Server"?
Anything running in IIS/ASP.NET really won't be long-running. It would be nice if you could just launch a workflow or something - but that's not realistic.
So you have to get the task out of IIS and into some other process.
Windows has a couple pre-built process models for this - one is MSMQ (System.Messenging) and the other is COM+ (System.EnterpriseServices). Though you should look at the new Windows AppFabric stuff, as that might now be a third option. Oh, one detail - MSMQ itself needs you to provide a host process - which is either COM+ or a custom Windows service.
Of these options, hosting MSMQ in COM+ is the most robust because they automatically provide retries, dead/poison message queues, etc. I wrote an article for MSDN about this a long time ago (probably in 2002), and it is a little complex, but very cool.
If you host MSMQ in your own service, you'll have to implement retries and some sort of dead/poison message handling, etc.
I haven't had time to look into AppFabric yet, but it may provide a simpler answer - I just don't know.
Thanks Rocky.
I need something way simpler than AppFabric. On the other hand, as you pointed out, I have to run these tasks outside IIS. I guess MSMQ on COM+ is what I can go with. But I'm not sure if MSMQ provides any mean to track details about execution of tasks that are represented by those messages. By that I mean customized details about how the task execution is progressing, provided by the task itself (perhaps passed to the Queue manager or something like that). I'm not very familiar with it. But a quick Googling (or Binging if you like) tells me there is something called Queue Journal. Do you have any better suggestion?
Thanks,
Amir
Again, I haven't looked at AppFabric enough to know - but it might be simpler than MSMQ/COM+, because that's not simple...
No external task mechanism is going to provide automatic execution status information. That sort of information is relative to the nature of the task itself - to your code - so you'll have to manage that.
Keeping in mind that we're talking about two processes running independently from each other, your best best for status information is probably to write "log entries" of a sort into a status table in your database. The polling business app can just check that table for status, and the task can write entries as it goes - including the final "I'm done" entry.
Thanks. Very much appreciate it.
Just a quick update for other readers' sake. I managed to do this using Quartz .NET.
Copyright (c) Marimer LLC