You could set up the windows portion of the task as a XML web service. That would provide both a method of retrival and some level of security. In lieu of a web service, you could us this as a CGI script that generates either a web page or download file when called. You could access the web server from the *nix box via www::mechanizeor lwp::useragent. I currently do this from one windows box to another.

Since you need to remotely run an as-yet undetermined program on a Windows box, I'd recommend that you install cygwin on the windows box and set it up to accept ssh connections. Then you can use Net::SSH2 to do whatever you would like. True, it's sort of a sledgehammer to kill a fly, but it will allow you to be more flexible until your requirements are set.

Don't use the cygwin perl though ... just don't

Mount the Windows box's disk on the unix box and use CIFS (samba) and the filesystem to communicate between the two. Have a driver program on the windows box that looks in an "inbox" folder for new stuff to do. This driver program would be the windows equivalent of a daemon--always running. When it sees files in the inbox, it processes them (by running the specialized software) and puts the result in an "outbox" folder. Also, have a program on the unix box watch the outbox and do whatever is appropriate to the files that show up there.

I have always felt that polling ("pull") solutions a last resort whenever a semaphore or other message system ("push") solution can be used. Pull solutions pretty much always use up more CPU time and RAM as you have to be always running, looking for something periodically. Conversely, a push solution means we only load what we need to load, when it is demanded of us, and we use literally no CPU time until that time.

Thus, I much more liked the ssh solution above than using a disk like this. If you are going to write a daemon anyway, have it listen on a port, and wait for communication on that port. Then it can do stuff based on what it receives there. This will mean more RAM used (but it can be swapped out if it's not active very much), but no CPU time (the OS will leave your app asleep until something comes in on the designated port). Especially in perl - perl makes writing client/server TCP apps very easy, not like C. So take advantage of that.

Regardless of what method you use, you will require a program or demon running on the windows box to recieve or notice the data, and run the windows program. You could use a rsh shell or a SOAP daemon or a program that monitors a directory, but something has to be there waiting.

And since you also have yet to write the script that interfaces with the COM object, why not combine the two and have the script open a port, wait for the inbound data, process it through the COM object and then return the response. Either Perl or Python are fine for that.