He Greg,

I had a project like that many years ago -- when security wasn't what it is today. It involved processing ACH transfers, which could pile up if a server went down, or if the flow was more than the existing servers could handle. I got it working, but it was cumbersome, and so I re-designed it to a) have one server be a listener; b) if a machine observed there was no listener, it became the listener; c) the listener assigned tasks to all machines that had registered as servers; d) if a task was assigned to a worker machine but went over a time limit, the Listener re-assigned the task to an open Worker. Thus, machines could be taken offline or added as needed (we didn't go so far as to fire up machines).

It all ran off data, as you probably surmised by now. Worked fast and great.

The client didn't like it because it wasn't DCOM. Oh well.

Today you would build it with queues, but I'm not at all certain that having it run the way I did 11 years ago wouldn't be the more robust solution, nor do I think queues would be faster.

The one thing I would do if designing it today, which was irrelevant back then, is use ParallelFox to utilize all the cores on a given machine. Each Worker would have an exe that ran multiple tasks in Parallel. The exe would, on completion of a task, mark it finished in the workflow table, and grab another to be run by the now empty process. PFox is ridiculously easy to use, fwiw. Great job by Joel.

Hank



>Hi All.
>
>In part of a recent project, I would like to call a remote outproc server (EXE) on a different machine. Therefore, off loading local task to other machines.
>
>Is DCOM still used? If not, what has replaced it?