Need help with DCOM

Greetings and Salutations!

I am getting into the DCOM thing and hope that someone can assist me.

I am trying to find a way to have several applications communicate over a network with the purpose of advising when a user has made a change to a record. This way they can all update their views to reflect the changes made.

I would also use this communication ability to have the programs do other tasks all at the same time such as shut down so that I can perform maintenance tasks.

I imagine a single controlling file would be on a main computer or server and the other apps would connect to it.

Does this sound right? Is there a working example available?

Thanks for reading this.

There used to be an example of this on the M$ web site. Dont know where it is now though since they no longer support the VB6. It was also one of the MCSD exam questions.... How to set up enterprise event notification.

To do this, you will need to understand the Singleton Pattern. Another pattern that could also be useful is the Observer Pattern.

The idea is to have a single object, which will be on the server, to which all the clients have a reference. All messaging must happen through this object. Whenever an object saves its data to the database, it must notify your Singleton of the fact. The singleton will then relay the message to the relevant clients.

Depending on how you implement your Data services layer, you will only be able to receive notifications of data changes that happen from your application. In other words, if a dba updates records in the database using SQL DML, then your application will not know to update the screens. For this reason, never assume that the data is the same as when you read it out of the database. If you are using ADO recordsets, ADO will check if any changes have occured. If you are not using ADO recordsets, you are going to have to come up with your own way of checking for changes.

If you are using pure DCOM, then use an ActiveX exe. This will allow multiple clients to connect to a single component instance and get a reference to the same instance of your Singleton.
If you use COM+, then you could develop the component as an ActiveX dll and set it up for single instance in COM+. This will achieve the same results as the ActiveX exe.

*** If you are using pure DCOM, then use an ActiveX exe. This will allow multiple clients to connect to a single component instance and get a reference to the same instance of your Singleton. ***

This is what I have done and I love it! It communicates on to all the other apps just like I want but only on my computer. I have placed the ActiveX on the server and linked to it but now have problems getting it all working.

Either I get permissions denied or it is permitted to create the instance and they are all out of sync and no communcation takes place.

I do not believe I am creating the connection to it properly.

Can you tell me the proper steps to make it happen in this case?

Thanks a bunch!

Security issues:
You will need to grant execution rights to the ActiveX exe on your server. You will need to use dcomcnfg.exe from your system32 folder.
Here's some help on that... http://support.microsoft.com/default...NoWebContent=1

Instancing issues:
How are your clients getting a reference to the Singleton?
When you run the ActiveX from your computer, can you run multiple instances of your exe clients and get the same instance of Singleton in each exe?

what is DCOM ?

Instead of piggy backing on allot of threads asking basic
questions, try searching the forums to get your answers. Then if
you still dont understand, then post your own thread.

Hey shunt,

I have it working and love it!!

Basically I have the activeX on machine [A]. On machine [B] I went into component services and in LOCATION identified that the activeX should be ran on machine [A] and in IDENTITY I selected Interactive User. I also had to add interactive User to the launch permissions for the component.

Thank you very much for your help.

Cool! :cool:

Quote:

---

Originally posted by Steve Stunning
[B]Hey shunt,

I have it working and love it!!

Basically I have the activeX on machine [A]. On machine I went into component services and in LOCATION identified that the activeX should be ran on machine [A] and in IDENTITY I selected Interactive User. I also had to add interactive User to the launch permissions for the component.

Thank you very much for your help.

---

Wow, I am trying to do the same thing you just did, I wonder if you could pass along more details...

I went into my Component Services admin tool, but I don't see the LOCATION thing you mentioned.

Where is that?

Well I think my server is set up correctly, but I get an error on the client side.

These are 2 WinXP Pro machine, in a Simple networking environment, no domain controller.

It says I dont have permissions to access the server basically, but the login name is the same on both machines.

With Component Services Open and running you can find location by doing the following:

[Left Tree]
Computers > My Computer > DCOM Config

[Right View]
Select your component
Right Click > Select Properties

New properties window opens with tabs at the top
General : Location : Security : Endpoints : Identity

This is where you will find LOCATION

Thanks Steve!

I think I have the server set up now, I just can't get a client to connect to it. Can you explain how you set up the client? I try and I get permission errors.

Dave

On the client machine you need to go into the properties for the component.

You need to select the location as the name of the common machine where the file will be access by all.

You will also need to change the Security settings so the client can access it properly.

Access Permission select Custom and add interactive user to the list.

Ya, I'm pretty sure I got all that right, but there's another permission thing that is stopping me - see picture. I can't open up the other machine from the client's side.

You are trying to access the remote system and will get this msg if you do not have permissions extended from that machine.

You should not need to access that area.

Just make the changes on your client machine and you should be OK.

Quote:

---

Originally posted by Steve Stunning
On the client machine you need to go into the properties for the component.

---

The component is not listed in the client's list. Here is a pic of the DCOM components on the server side. It does not appear on the client. Do I need to somehow add it?

Thanks for all your help!


Dave

With DCOM, the component does not appear on the clients DCOM component list. Only server components residing on the PC will appear in this list.

To instanciate a class you should be able to use CreateObject from Visual Basic using the class name and server name.

VB Code:

set obj = CreateObject("myproj.myclass", "myserver")

This is actually an interesting one. Surely the location of this component should be transparent to the application.....??? I know when you are using ActiveX DLL's with COM+ you would need to export a package to be installed on the client machine that would reroute calls to the server. I tried to find a similar thing for ActiveX EXE's, but couldnt find anything.

I remember that the proxy for the DLL just writes a registry entry that tells COM to reroute calls to the server. Perhaps you can create a registry entry for ActiveX EXE's that does the same? I'm not sure....

If anyone comes up with a method, please inform the rest of us.

Dave Sell

I did so much testing that I believe I ran the exe on the client machine and received the entry. Then I changed the properties so that it would run on the server.

Is it working then?

I am at work, so I will not be able to tesdtit again until I get home tonight :(

I will try executing the ActiveX EXE on the client, but I have a feeling that will not in effect register the object with the OS>

I know in order to register an ActiveX DLL or OCX< you have to run REGSVR32.EXE on the file.

I do not know how to register an ActiveX EXE...

Do you?

Thanks for all your help, I can't wait to get this working, this is very insightful!

Dave

Ya..!!

The ActiveX.exe controls runs on one machine and pases along info the clients that are connected.

The client software makes a connection with the ActiveX and holds it open. The ActiveX has an internal feature that keeps track of how many connections have been made so when 0 connects are found it ends.

I pass test messages from the client software thru the ActiveX and it in-turn passes these messages to the other connected clients. I can add instructions such as Shut down or end the client program. You are only limited by your imagination.

Quote:

---

set obj = CreateObject("myproj.myclass", "myserver")

---

Er, this was not the exact semantics I was using on the client!

I was using:

VB Code:

set obj = CreateObject("myproj", "myclass")

The way you would do it as if you were on the server...

I better try it the right way on the client as soon as I get home.

Quote:

---

You are only limited by your imagination

---

This is what excites me the most - I have a huge capacity to imagine the possibilities!

I will definately let you all know if/when I get this working and I will post a tutorial when I do.

Steve, did you look at my other post a while back?

http://www.vbforums.com/showthread.p...hreadid=304832

What are your thoughts on this?

Dave Sell


I just ran it. It registered it on its own.

It will register ActiveX's when you run them on the machine.

If you delete the ActiveX EXE from the client pc, does the application still run?
Is it actually running the ActiveX on the server from the client, or is it running the ActiveX on the client?

I am not sure but I imagine it would run if directed to run elsewhere. You only need the registration so you can redirect it.

If the local client ActiveX is being used then will be NO communication between the other client computers. It would only communicate locally with other instances of your app. This is fine if you only need to comunicate locally with your apps.

If you are connecting with the ActiveX on the server then all the client apps on any computer will be able to communicate as one. This single instance of the file would be held open and all commuication would obviously pass thru it.

Sorry, I must have missed the point somewhere...

Are you creating a central server or a local server?

I remember seeing a setting in the DCOM cfg mgr on the server that you could make the EXE run on the server or on the client or even on some other machine?

You are talking about the location under properties for the control. Yes.. This option is available on all computers.

On the server it is "run on this computer". On the Client it is the location "run on the following computer" and select the server name.

Well, I hate to say this but I screwed myself. This morning, I actually had DCOM working against a "Test" DCOM control (No Binary Compatibility)

The client instantiated a server-side ActiveX EXE!!!!

Anyway, I had a local copy I had to run first, to get it to show up in the DCOM CFG MGR thingy.

So I wasn't 10000% sure which copy I was running. So I changed a little tiny section of code (I did NOT change the interface) and re-compiled the DCOM server object.

Lo-and-behold, the client no longer worked!!!!!!!!!!!!!!!

f-me!

I set the server to binary compatibility and tried to do everything over, but the client is still acting like a ******.

So, I think this counts as a success, but I am gonna try it all over again with a new server project, and make it Binary compatible before I "publish" it.

I'll get back to you on my "progress" LOL!

Dave

HAH!

I know how you feel becasue I went thru the same thing. But you have proven that it does work. The problem you have now is the registering of the ActiveX.

I suggest you go thru the registry and delete ALL the entries for it and then run your new version.

It should work as before. The problem is when you recomplied it and ran it again it probably registered differently and you are still connecting to the old version.

Best of luck to you.

Quote:

---

Originally posted by Steve Stunning
HAH!

I know how you feel becasue I went thru the same thing. But you have proven that it does work. The problem you have now is the registering of the ActiveX.

I suggest you go thru the registry and delete ALL the entries for it and then run your new version.

It should work as before. The problem is when you recomplied it and ran it again it probably registered differently and you are still connecting to the old version.

Best of luck to you.

---

Do you use Binary Compatibility to solve this problem?

I used Project Compatibility.

Does that imply that you have both your Client and your Server in the same project?

Is that required?

Thanks!!!!!!!!!

No.


They just use the file as needed. The ActiveX needs to maintain compatibility for registration purposes only.

Right, which is why I would use Binary compatibility. Is that a good choice in your opinion?

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

But please keep 1 aspect in mind with serverside run dll's/ activex's, as you have 25 or less clients connecting to it, there's isn't really an speed issue.
But when the numer of clients get above that, the network becomes the bottleneck as the problem with serverside activex's is that COM+ uses Variants to marschall it's data between client and activex.
This will clog up youre network eventually.

Quote:

---

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

But please keep 1 aspect in mind with serverside run dll's/ activex's, as you have 25 or less clients connecting to it, there's isn't really an speed issue.
But when the numer of clients get above that, the network becomes the bottleneck as the problem with serverside activex's is that COM+ uses Variants to marschall it's data between client and activex.
This will clog up youre network eventually.

---

I think the interest has been here for a long time, but the realization that the ability to implement DCOM in a VB6 paradigm is finally sinking in.

I take issue with your point on DCOM network traffic. Keep in mind you can take more steps to minimize DCOM noise on the network - namely using a quiet protocol like TCP/IP and not using a noisy one like NETBUI.

I cannot believe that a mere 25 clients can saturate a 100 Mbit TCP/IP ethernet network? There are more steps that can be taken to optimize your network topology as well.

If you are using a HUB between your DCOM server and your clinets, then your performance will decrease linearly with respect to the number of units attached to that hub.

However, by using a "switching" hub, (or SWITCH), you remove an important bottleneck, as it allows full thoughput of every device attached to it.

Another approach is to "step up" the link between the switch and the server to a Gbit ethernet connection while leaving each connection to the client to run at 100 Mbit.

Let's not forget to mention the "horsepower" of the server itself. It should probably be a good 2GHz if not faster with plenty of RAM. Multi-CPU would be nice also.

I guarantee you will not saturate a Gbit backboned, network switched, high-powered TCP/IP server configuration with a mere 25-50 DCOM clients.

That being said, I will agree that for any given topology, there will be some maximum number of DCOM clients it can handle. Sounds like some emperical research will be required to pinpoint that number, but if you could provide some bandwidth requirements of a single average DCOM client (wrt Tx bytes/s Rx bytes/s) I could come up with a projected estimate.

I'll go out on a limb and offer the number of average DCOM clients the above ideal scenario can handle without saturating the network is more like 500.

I have seen people using COM+ to hurl complete recordset's (10.000+ records) over the network, i just mentioned this cuz people should be aware of the network strain an COM+ architecture could create.
I wouldn't know how an Gbit network would react to and COM+ architecture that hurls complete recordsets over it.

And remember loads of company's doen't have that kind of infrastructure and an software produckt that would require an hardware investment wouldn't be as succesful as one that does the job on the existing network.

SQL server doesn't really need an heavy machine remember, it just needs loads of memory.

Quote:

---

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).

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.