Architecture decision - should components communicate via the DB?

[Paul]

I have decided on a basic architechture to quickly refactor two
processing functions of my winforms application until we get the
chance to rewrite it. Basically it will consist of 2 applications:-

1. A service running on the server to take jobs from a queue table in
a SQL database, perform the job (could be 1 minute or up to an hour or
more) and write the results back to the database.

2. A .NET web application to submit the job requests into the queue
table. (Initially a combo box with a button marked "Process".)

One thing we hope to achieve with this is I would like to keep the
door open to have multiple servers all processing simultaneously
should that become necessary (as we hope it will!). Another thing is
decoupling of the components - eg the server crashes and it (or other
servers) will continue to process jobs on restart as they are queued
safely in the database, while clients can continue to submit jobs and
perform other work.

My question is, should I worry about giving feedback to the client
application and if so how? Two alternatives with minimal overheads
might be
1. Email the client to say "Your job has completed".
2. Write progress info to the database for the web app to pickup and
display back to the client

Given the jobs could run a long time and the user may just wish to
close the browser and move on, is it worth writing code (and
processing overhead) to inform him of progress with one of the one
minute type jobs?

Your thoughts on this question or the architecture decisions in
general would be much appreciated.

cheers,
Paul.

 

[Cowboy \(Gregory A. Beamer\)]

Given the jobs could run a long time and the user may just wish to
close the browser and move on, is it worth writing code (and
processing overhead) to inform him of progress with one of the one
minute type jobs?

No. I have seen people attempt this, but it ends up with a lot of code that
is largely useless. Once you have it started, you will be working against
sunk costs and attempting to find a way to add the notification to the
user's browser.

Now, if you have a set list of users, a small app that runs in the task tray
and pops up "your job is done" is not a bad idea. I have worked on a team
that succesfully did that. But, an email message is probably fine until you
figure out what the app is going to be when it grows up.

I would not invest time in trying to contact a web client. It is a major
pain that is not worth the effort. Just my two cents.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************

 

[Paul]

Hi Gregory,

Thank you for your reply, it is much appreciated.

In this same scenario, is there a preferred method to "push"
information from the server to the (local) service application or your
suggested tray application on the client?

eg the service running on the server could continuously poll the queue
table in the database but that would generate load on the server when
there is no job in the queue, and there would probably be an
unnecessary delay when there is a job waiting there.

Is this when you use Notification Services?

cheers,
Paul.

 

[sloan]

This is an old and abandoned application block.
http://msdn2.microsoft.com/en-us/library/ms998466.aspx

but you might want to take a look for ideas.

...............

Several years back, I worked for a company that modified this block.
They had about 4 status.
Submitted
Working
Failed
Completed.

The results were always in a generated html file.

Once you submitted a request (for a long running report)...you were sent to
a screen that showed all your requests.
The one you just added....showed up and usually it was "Working" (maybe
Submitted if the Queue was backlogged)

So once it was "Completed", you would get a link....to a "double guid" html
file.
example
http://www.mysite.com/reports/D2CE8CCD6B984d32A7642A03F5810000/AAAA6B35CCA74bd1A5A895BF9C828B30.html
its hard to see, but there are 2 guids..one is a directory, one is a
filename.

We had a clean up script that would delete files (and db entries) for
reports older than 2 weeks.

And we also optionally email you when the report was finished. We put your
email address in a cookie...but it was optional.

It worked pretty good.


It I were doing it today....I might keep the idea of the application block.
But I'd use WCF (IsOneWay) messages.

And I'd write a common interface...and would definately wire up events

public interface ILongRunning
event JobSubmittedHandler JobSubmittedEvent; // wire up the delegate as
well
event JobInProgressHandler JobInProgressEvent; // wire up the delegate
as well
event JobFailedHandler JobFailedEvent; // wire up the delegate as well
event JobCompletedHandler JobCompletedEvent; // wire up the delegate as
well

(or something like that)

then you can keep the implementation seperate from the handling of
events,.which would write to a db log and/or email people.

I'm talking free-lance here, so take anything I say with a grain of salt.

...