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