Architecture recommendation needed

[Jeff Johnson]

[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]]

Yup, the better approach would be to use remote events, its the callback
mechanism you were referring to.

 

[Jeff Johnson]

Yup, the better approach would be to use remote events, its the callback
mechanism you were referring to.

Could youi tell me what the MSDN topic is that discusses this technology? I
typed "remote events" into the Index tab and got nothing.

 

[William Stacey [C# MVP]]

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.

--
William Stacey [C# MVP]

| [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]]

google .net remote events several links.
However, william does have an excellent point. I would add to his
suggestions MSMQueue or whatever they are calling it now