Need help with DCOM

[Dave Sell]

Originally posted by Calibra
Nice to see so much people taking an interrest in (D)COM or COM+ as it's known now.

Say, aren't COM/DCOM and COM+ seperate animals? I thought COM+ was .NET's new version of COM. And they are not trivial to mix (ala oil and water).

[farid mahini]

Hi,

I am having problem accessing my vb6 ActiveX.exe from a client host. I read all the responses in this thread but have not been able to get it working yet.

I have no problem connecting to the ActiveX from my client app as long as it's on the same PC. Once I register the activeX on my server (std win2k) and run the dcomcnfg, it shows one of the public classes only (the activeX exposes 7 classes). Is this correct?

Also, in the component services, I do not find a DCOM config as noted by Steve Stunning. Is it because I am running VB6 professional ? DO I need the Enterprize version for DCOM to work?

I was able to access my activeX from another PC using Remote Automation, but it does not support events.

Thanx in advance,
-Farid

[dilettante]

Great to see more experimentation with and appreciation of DCOM. It's a fantastic technology for LANs, basically an ActiveX wrapper on Windows RPC.

COM+ is the Win2K (and later) version of Microsoft's earlier (NT4) MTS (Microsoft Transaction Server) and DTC (Distributed Transaction Coordinator). In the .Net world they call this "Enterprise Services."

Its purpose is a bit different from DCOM itself in that it manages distrubuted transactions (2-phase commit of updates) and object pooling including OLEDB connection pooling. However it can wrap both DCOM servers and the .Net equivalent.

Don't worry about COM+ at this point. I think confusion comes in due to the naming and the fact that the same MMC snap-in is used to manage both DCOM and COM+, since they are typically used together in a COM+ situation.

If you need to support 9x machines too be sure to get the DCOM95 and/or DCOM98 packages. I don't think they are installed by default with Win9x.


The network performance comment is a red herring. If you pass too much data around you'll see performance problems whether you use DCOM, Web Services, MSMQ, or raw TCP with a hand-coded protocol on top of it.

The warning isn't worthless however. You'll want to be careful to avoid things like passing large data items or objects ByRef when you only need them ByVal. You also want to just plain avoid passing data around that you don't need to. PropertyBags do indeed have their place but don't go nuts with them, in many applications they'll just add unnecessary complexity.

In places where a monolithic (stand alone) program might pass a String or Array or UDT ByRef to avoid copying, it you'll be better off passing it ByVal to a DCOM method if you don't need to get it back updated. Anything passed ByRef has to be copied TO the server method and then copied BACK to the calling client.


Application needs differ, but ideally the DCOM client should be reduced to a presentation (UI) tier, little more than something like a web browser. Push most of the logic, data access, and crunching into the DCOM server (ActiveX EXE). This way you'll have less data to move in those DCOM calls - no shuffling whole Recordsets via DCOM, just the results to be displayed and the user input to be processed.

The server works harder this way but if the database is "near" it (on the same machine or a local fast network segment) you'll see a big performance improvement over the typical 2-tier system where each client connects to the database itself. Thread pooling in the ActiveX EXE helps keep things from getting... well, single threaded.

[dilettante]

Actually one of the main reasons MS came up with .Net was to get rid of COM, as COM is one of the reasons there are so many Buffer Overflow Exploits in windows (due to lazy programmers).
But because there are still so much legacy COM app's out there MS was forced to support COM under .Net.
But it will phase out eventually, but when? Nobody knows

I'd disagree with almost 100% of those comments, but I'm not looking for a fight.

.Net eschews COM mostly because C++ programmers hated working with it. .Net Remoting is an attempt to replace DCOM.

COM+ is a core feature of .Net, intended to compete with EJB and similar technologies in the Java space.

The primary source of buffer overflow exploits in Windows occurs in C and C++ code. COM/ActiveX had more than its share of security issues but it had a lot more to do with the ease of deployment of COM components via IE.

And COM/DCOM are here for a long time.

COM: Component Object Model Technologies

Is COM still supported? Is it going away?
COM is a feature of Windows. Each version of Windows has a support policy described in the Windows Product Lifecycle. COM continues to be supported as part of Windows. COM is a feature of the next version of Windows, Windows Vista.

[dilettante]

One last thing while I'm thinking of it:

Even with DCOM95/98 installed, a Win9x machine cannot start your DCOM server on demand. You need to run it on the 9x server explicitly before it will be availalbe to remote clients.

Typically this is done by starting it as a Win9x Service but it is possible to just put it in the Startup group for simple applications.

[dilettante]

I have been unable to get my DCOM components to work on Windows Serve 2003. Do you have any experience with this, or documentation to get DCOM running on Windows Server 2003?

I'd have to do some research myself, but here are some thoughts.

Win2003 locks down a lot of things by default. DCOM depends on the Windows RPC Service for one thing, and the RPC ports may even be blocked by the Windows Firewall by default. Usually enabling File & Print Services takes care of that and this can be an issue for WinXP users as well.

There are also some tools to manage Win2003's "role" as a server. There may be an option in that "Manage Server Role" applet to allow Win2003 to be a DCOM server.