Hi Gary
IMO, you are right with persistent DCOM objects being a No-No.
But I wouldn't go so far as to write a custom IP socket listener, with so good standard options available:
I would personally use:
1) If you have COM+ available (W2K), distributed COM objects -in each site- called in a
stateless mode; each request carries all the necessary info (as parameters) and returns all necessary results (in the return value, typically an XML string). Each object is released as soon as the method returns.
COM+ is very reliable and efficient for working this way, if you do it right. I can't speak for DCOM on this matter because I didn't use it.
2) COM objects on each site, exposed as Web Services (thru Soap Toolkit 2.0, using the ISAPI implementation which is faster). Note that basically it is the same thing than before, with just an additional SOAP wrapper: stateless method calls which return all the info in one single message...
HTH
Jose
DCOM servers on each site -as you have- but in a stateless, no persistent objects a
>I have an application with 8 installations on a WAN. I have written a "head office" application that needs to collect & collate data from each of the sites.
>
>Each site is a separate VFP6 application (shortly to move to VFP7) with it's own set of DBF's.
>
>I have written the head office app in VFP7 using DCOM objects located in each of the sites, however both the network and DCOM are proving unreliable. Lost connection, slowing the site servers (taking 100% CPU!)
>I think the bottom line is that persistent objects across a WAN are a No-No.
>
>I now need to (very quickly) re-write my app to avoid DCOM so far I have two ideas/theories;
>
>1. Create an HTTP service for head office and host in each site (disadvantage is that each site needs to become a web server)
>2. Create an IP Socket application that "listens" at each server and replies to IP requests.
>(Disadvantage non-standard and little knowledge)
>
>Can anyone with any ideas/thoughts ??
>
>Gary Williams
