>I thought that the difference between COM and DCOM was whether the component ran on the user's machine or on the server? This obviously isn't the case since you've said the above AND you've said I shouldn't use DCOM. What am I missing?? Simply put, how does DCOM differ from COM?


COM and DCOM are based on the same technology. Really, DCOM is just a
special set of restrictions on how COM is used. The concepts of how
servers are built and implemented varies very little - that's the beauty
of COM - one interface servces both local and remote instances of your
objects.

From a VFP perspective, building a DCOM server means you have to build
an EXE server. Local COM servers can compile either as a DLL (In Process)
or EXE (Out of Process). Since DCOM runs no another machine it obviously
cannot run In Process, hence the EXE requirement.

DCOM is very powerful, but it doesn't work well for anonymous applications
(where you need to have *anybody* access data or the server). The reason
for this is that DCOM works as part of Windows and the security structures
that govern Windows - hence you can configure DCOM servers to specific
user accounts and groups, but you cannot make DCOM servers be accessed
by just anybody. HTTP on the otherhand allows that flexibility. Rather
than using a specific account thte Web server can instantiate the COM/DCOM
object and impersonate an account that you deem safe. This means anybody
can access the server, yet the COM object is still goverened by the NT
security rules which are now channelled through the Web application.

This is one of the main advantages of Web applications - they act as a
front end - a sort of route - for an application, to avoid giving anonymous
users direct access to machine resources. A Web app, can pool resorucesa
and security in ways that would be impossible with direct access to these
resources.


+++ Rick ---