Need help with DCOM

Quote:

---

Originally posted by Dave Sell
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).

---

D(istrobuted)COM is an sort of extension of COM created on the base of COM to make it possible to use te COM princaple thru an Network.
DCOM was renamed to COM+ when MTS (microsoft transaction server) was introduced.

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

MTS was the latest addition to the COM technology, which can be used to created packeges of COM+ components that can cooperate as one component.

I must admit I did wonder about holding the traffic open with the server while multiple users were connected using the ActiveX file.

Personally I figure it would be OK in my applications where a small number of people would be using it and the data displayed to the users needed to be updated real time.

I do like the power of linking the applications and pass information or commands. I always knew it could be done and now I have created my own little monster.

So do you have this set up as a service? Where multiple clients talk to the same instance of the server? Do your clients use GetObject, or CreateObject?

No not as a service. I am going to play around with that next. I have some samples that work.

Mine is just the ActiveX file on the server. When the program runs I obtain the connection using to the ActiveX (Extender) and the Connector class

Public oConnector As New Extender.Connector

This reference is directed to the server and not the local computer. I have it working on my home network as a little chat program.

Why bother setting up the ActiveX as a service? COM+ is doing that for you. In any case, your ActiveX EXE will not run as a Windows Service under NT4 if you use VB6 and NTService control. Well, more like it is very unstable. Other than that, you will need to write it in C or now .NET.

To comment on Calibra's performance issues, I think its up to design. You should not be passing object references accross the network! That will result in nasty marshalling accross the network. You should rather serialize your objects into PropertyBag and send content as string accross the network. This will eliminate your marshalling. Yes, it will be a performance hit in serializing the object, but it is a lot less of a hit than marshalling. Take notes from .NET. This is how its done now. Also, your Connector class should be a singleton and stateless. In fact, all classes in your server should be stateless. You should be using it as an API really... Calling functions and getting returns.

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

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.

Quote:

---

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

Quote:

---

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.

---

dillettante,

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?

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.

Quote:

---

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.

Someone told me there is a special group called DCOM group that is new in Windows 2003. I am looking for some comprehensive documentation regarding this matter. It is a tough sell selling new customers on buying Windows Server 2000. They all want Windows Server 2003 and soon enough the next version.

Two documents you might look through are at:

Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1

Changes to Functionality in Microsoft Windows XP Service Pack 2

Also see Release notes for Windows Server 2003 Service Pack 1 and scroll down to "Certificate Services: Effects of security enhancements to the DCOM protocol."

One more resource before I stop posting in this thread:

How To Create a DCOM Client/Server Application

Info and links there for VB5 and VB6, some tips on troubleshooting too.