>>Hi Rick -
>>
>>I think I'm *finally* starting to get the picture. There is one big hole in my understanding tho.
>>
>>We've said the following:
>>>>3. When you are talking about 'running the component'. Does this happen on the server or on the user's machine?
>>>
>>>On the server. Clients access a Web page which responds and runs the component
>>>on the server.
>>>
>>>>4. If I set up an ASP that calls my DLL, how do I setup and distribute this? Is it something that each user has to install or just something I set up on the server?
>>>
>>>You don't. You only have a single server (the Web server) which uses your
>>>component. Everybody accessing the app just uses a browser
>>
>>
>>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?
>>
>>Thanks again!
>> ~ellen
>
>You have the right idea. However, in a web application, you have to think connectionless. The user is not going to run an application on their PC that will instantiate the object on the web page. The Active Server page will accept the input from the HTML form (displayed on the user's machine), instantiate the object (your DLL), pass the parameters to the object, receive the result of the object's method, and send a new HTML page to the user. In this case, COM will be used between the ASP (running in IIS) and your component. If the component is running on a different machine other than the web server, then DCOM will be used. The user has no knowledge that this is what is happening.


Just adding to what Craig has said-- DCOM will be Slower pound for pound. My practice is until you just can't do it leave it on the same box.


HTH
Jeff