|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Architecture recommendation neededI'm setting up a small distributed application. Clients will have a UI and submit jobs to a server. Beyond simply needing to know when the job completes, there may be stopping points where the operator needs to take manual action. Simply put, I'm making a small-scale workflow system. I'm not a fan of polling. I don't want the client app constantly pinging a database or Web service to query the status of jobs. I'd rather there be a callback mechanism and the client only be notified when an "interrupt" occurs. To this end I was wondering about remoting, although it may be overkill for what I'm doing. I was thinking that the client app would expose a remote object and then include its URI along with all the information needed to run the job. Then, when the server needed to tell the client something, it would dynamically create a channel based on the URI and call the object. If the client isn't up (the operator submits a job at 5:20 and goes home at 5:30; the job needs a response at 5:45) the server will write an entry to a DB or message queue which the client app will check the next time it's started. Are there better methods for this kind of scenario? Any pointers would be appreciated. Yup, the better approach would be to use remote events, its the callback
mechanism you were referring to. -- Show quoteRegards, Alvin Bruney ------------------------------------------------------ Shameless author plug Excel Services for .NET is coming... OWC Black book on Amazon and www.lulu.com/owc "Jeff Johnson" <i.get@enough.spam> wrote in message news:%23SLFGToNHHA.2028@TK2MSFTNGP03.phx.gbl... > [VS2005, i.e., Framework 2.0] > > I'm setting up a small distributed application. Clients will have a UI and > submit jobs to a server. Beyond simply needing to know when the job > completes, there may be stopping points where the operator needs to take > manual action. Simply put, I'm making a small-scale workflow system. > > I'm not a fan of polling. I don't want the client app constantly pinging a > database or Web service to query the status of jobs. I'd rather there be a > callback mechanism and the client only be notified when an "interrupt" > occurs. To this end I was wondering about remoting, although it may be > overkill for what I'm doing. I was thinking that the client app would > expose a remote object and then include its URI along with all the > information needed to run the job. Then, when the server needed to tell > the client something, it would dynamically create a channel based on the > URI and call the object. If the client isn't up (the operator submits a > job at 5:20 and goes home at 5:30; the job needs a response at 5:45) the > server will write an entry to a DB or message queue which the client app > will check the next time it's started. > > Are there better methods for this kind of scenario? Any pointers would be > appreciated. > "Alvin Bruney [MVP]" <some guy without an email address> wrote in message Could youi tell me what the MSDN topic is that discusses this technology? I news:OGjpuY1NHHA.4260@TK2MSFTNGP02.phx.gbl... > Yup, the better approach would be to use remote events, its the callback > mechanism you were referring to. typed "remote events" into the Index tab and got nothing. Your needs may be simple, but this is kind of thing is rip with failure
points which could very hard to cleanly fix without a lot of manual inspection. Sql Service Broker would seem to be a good fit here as tasks can be long running, async, persistent, and atomic. Submit a job using SB. Client can then poll on queue replies (i.e. manually or automatically) or use the event method in SB. This would then make things like manual task points extremly robust and fairly simple. Send a message to an operator queue. When complete, the message can be sent on to another queue, etc. -- Show quoteWilliam Stacey [C# MVP] "Jeff Johnson" <i.get@enough.spam> wrote in message news:%23SLFGToNHHA.2028@TK2MSFTNGP03.phx.gbl... | [VS2005, i.e., Framework 2.0] | | I'm setting up a small distributed application. Clients will have a UI and | submit jobs to a server. Beyond simply needing to know when the job | completes, there may be stopping points where the operator needs to take | manual action. Simply put, I'm making a small-scale workflow system. | | I'm not a fan of polling. I don't want the client app constantly pinging a | database or Web service to query the status of jobs. I'd rather there be a | callback mechanism and the client only be notified when an "interrupt" | occurs. To this end I was wondering about remoting, although it may be | overkill for what I'm doing. I was thinking that the client app would expose | a remote object and then include its URI along with all the information | needed to run the job. Then, when the server needed to tell the client | something, it would dynamically create a channel based on the URI and call | the object. If the client isn't up (the operator submits a job at 5:20 and | goes home at 5:30; the job needs a response at 5:45) the server will write | an entry to a DB or message queue which the client app will check the next | time it's started. | | Are there better methods for this kind of scenario? Any pointers would be | appreciated. | |  |
|||||||||||||||||||||||
Other interesting topics