first of all, you're groupings are incorrect.

COM+ is a combination of COM, DCOM, and MTS.

and secondly, there is no comparison to do, or argument for or against "DCOM vs. COM+/MTS".

DCOM stands for Distributed Component Object Model. this means that you can install your COM .DLL file on ServerA, and use that specific from Workstation1, or any other computer on your network.

MTS is Microsoft Transaction Server - this is a transactional based service provider. what this means, is that you can put your .DLL files (or whatever file) into MTS and have true Transactional capabilities - meaning that you set up groups of functions in a transaction. If any of these functions fails, then the entire group of functions is cancelled, and the transaction is rolled back.


COM+ is the combination of COM, DCOM, and MTS into one simple package, instead of 2 (technically 3) seperate packages. COM+ is built into the operating system of Win2k (and XP)

dredge - DCOM implies out of process server and therefore must be an ActiveX EXE not a DLL

Regards
GK

GeoffKell:

you are correct.

but couldn't you also create a DCOM instance using DLLHost.exe?

DLLHost.exe - is dcom utility to run a dll on remote server, because you need to have a process to host dll.
this is the worst scenario to run a remote component

dcom/mst/com+
full story on http://www.microsoft.com/com/wpaper/compsvcs.asp
http://www.microsoft.com/msj/0198/mtscom/mtscomtop.htm

for small projects you can use activex exe, for big ones actvexdll + mts / com +

Thanks for the info, guys, you're helping me bring it together.

So, you're saying I'm missing the point.

Is it correct to say:

1. MTS and COM+ provide an environment that enables DCOM.

2. "Out of process" ActiveX EXEs don't need MTS/COM+ to be DCOM-enabled (as they have their own process).  

3. ActiveX DLLs do need MTS/COM+ or similar to be DCOM-enabled, as they are "in-process" (and so it follows need a process to be in).

4. DLLHost.exe should be avoided as it's a bit shoddy.

Having made the points above, we can say:

(Now, stay with me here, I'm going even further back to basics.)  You can't call a DLL on one machine from an exe client on another machine without the DLL having a process in which to run.  Processes cannot be transfered across machines.

So, the client could call an ActiveX EXE on the server which could in turn call the DLL.  The DLL would run in the same process as the ActiveX EXE.

But, Microsoft have kindly built a very sophisticated ActiveX EXE called MTS so why not use that?

>>>MTS and COM+ provide an environment that enables DCOM.
It is not exactly correct
History :
DDE ? OLE Automation ? COM ? DCOM ? MTS ? COM +
DCOM ? was before MTS, and as you  stated MTS simplified DCOM development.


COM + - With the release of Windows 2000, all the best ideas of COM, DCOM and MTS have been integrated into a new run time named COM+. Unlike MTS, this new run-time layer isn?t optional. COM+ is part of the default installation of Windows 2000. But the good news is that the COM-versus-MTS dilemma doesn?t exist on Windows 2000. Moreover, writing components for COM+ is easier than for MTS because many of the annoying idiosyncrasies associated with MTS have gone away.

>>>But, Microsoft have kindly built a very sophisticated ActiveX EXE called MTS so why not use that?

It true, but MTS is additional overhead plus you need to install it on your server. (COM + is included with 2000).

Thanks rkot2000.

So before MTS, DCOM was limited to ActiveX EXEs?

no, you could use dllhost.exe to run DCOM .DLL files, before MTS.

dredge is correct. microsoft named this : surrogate process

again back to msdn :

Running in-process components remotely: Surrogate
In order to run in-process components remotely, a surrogate process on the remote machine is required. In addition to enabling remote execution, surrogate processes offer the following benefits:

Faults in the in-process server are isolated to the surrogate process.


One surrogate process can service multiple clients simultaneously.


Clients can protect themselves from untrusted server code, while accessing the services the server provides.


Running an in-process server in a surrogate gives the DLL the surrogate's security.
Windows NT 4.0 Service Pack 2.0 and DCOM for Windows 95 introduced a default surrogate process, as well as a protocol for writing custom surrogates. The default implementation of the surrogate process is a mixed-threading, model-style, pseudo-COM server. When multiple DLL servers are loaded into a single surrogate process, this process ensures that each DLL server is instantiated using the threading model specified in the registry for that server. If a DLL server supports both threading models, then COM will choose multithreading. This surrogate process is written so that COM handles both the unloading of DLL servers and the termination of the surrogate process.

Oh , ok, but dllhost doesn't give you any of the sophistication of MTS, which I guess is why rkot2000 said about using dllhost "this is the worst scenario to run a remote component".

I wish I could give you all some points, but
rkot2000 gave the fullest answer (in my opinion).

Thank you all very much.

just so you know,

it's common for a person to create a new question specifically directed towards a user (usually something like "Points for UserName") so that more than one person can get points for one question.

when you do this, you have to reference the question that the person helped you on, otherwise the EE staff consider it gaming and may kick both of the accounts off the site.