Login: Automation over DCOM

Introduction

We have learned, what automation is and created a login management automation server and automation client applications. But wouldn't it be nice, to extend our learning over DCOM, so that the client applications can communicate the server over the network on different machines, through DCOM. This would make our application more powerful and would justify the logic of creating the Login server and client applications different and not mixing the code of both into one.

What is DCOM?

DCOM is an acronym that stands for Distributed Component Object Model. It can be seen as the next logical step over COM. DCOM enables the COM programmer to extend their components over network, giving them the benefits of distributed computing. We had build the automation server application to be used over the network. Remember COM 'DLL' can not be used over DCOM. When the client and component both resides on the same computer they communicate with the help of Local Procedures Call (LPC), but over the network they have to use the DCOM proprietary standard built by Microsoft. COM components over the network behave the same way as if they are on the same machine with the client.

DCOM helps our components to become location independent. Our login server brings us the power of distributed computing while maintaining the consistency of the database. There may be situations like, we are developing a software for a 10-20 computer network (e.g. cyber cafe) and we couldn't afford to use the costly MS-SQL Server, etc. This technique of database management comes to our rescue.

The DCOM comes pre installed on Windows NT and Windows 2K and I hope on Windows XP too. If you are using other versions like Windows 9x, then you must check that the DCOM98 extensions are installed on your computer, otherwise check for the DCOM98 extensions available here.

Prerequisite:

This tutorial assumes that you are familiar with Visual C++/MFC, COM/DCOM, Automation, Windows Registry and other technologies used in this tutorial like ADO, etc. Though there is no need to understand their underpinnings in great detail, you should at least have a working knowledge of what these underpinnings mean. Most important of all, you should take a glance over the login automation server and automation client examples.

Suggested Reading

• How to build an automation server using MFC?

  Login: Automation Server.

• How to build an automation client using MFC?

  Login: Automation Client.

Implementation

Now, after enough introduction, we are all set to exploit DCOM through our component. We will do that by changing the registry entries of our computer and hard-wiring the registry entries, so that the client can connect to a remote component, on another machine.

Before going forward, always remember that changing the registry entries will be fatal and can crash the system. So, don't try this at home, these stunts are performed by software professionals only after a good knowledge of Windows registry. Hey, you don't have to worry much, as you are a homosapien, you can do what you are told not to do, just like people read this warning: smoking cigarette is injurious to health and forget it.

• First run the component on all the clients and on the server machine, then remove the component from all the client machines, if you wish.
• Copy the client application on all the client machines.
• By running the component on the client machines, we have the necessary registry entries as a starting point, which we can manipulate.
• Find the registry entry on the client machine: HKEY_CLASSES_ROOT\CLSID\HKEY_CLASSES_ROOT\CLSID\{C42854AB-3175-4E27-8569-CC55C63A107C} and delete all subkeys under it except ProgID. The hexadecimal value is the class id of our automation server.
• Add a new string property named AppID to the key: HKEY_CLASSES_ROOT\CLSID\HKEY_CLASSES_ROOT\CLSID\{C42854AB-3175-4E27-8569-CC55C63A107C}, with the class ID of the automation server as its value.

  

• Add a new key named {C42854AB-3175-4E27-8569-CC55C63A107C} under the HKEY_CLASSES_ROOT\AppID and add a string property to it named RemoteServerName with the remote machine name as its value.

  

• Now you can run the client application on the client machine, the component will run on the server machine and will be terminated in a minute or less.

Conclusion

This brings us to an end of our long journey through automation to DCOM. We have successfully built an automation component and client for it and used it over DCOM, through our very own MFC and it doesn't take much energy. It also opens the doors of automation and DCOM for a bright and long path of component software development for us. Your valuable suggestions are always welcome, to make this article better.

Copyright:

This code is provided "as is" with no expressed or implied warranty. You can use and abuse this code without any restriction. If you use this source code in any commercial product, acknowledgment is not required but would be appreciated.

Bibliography:

• VC++, COM and Beyond.

  Author: Yashavant Kanetkar & Sudesh Saoji.

  ISBN: 81-7635-206-8

  Publisher: BPB Publications.

  User Level: Beginning-Intermediate.

  This book provides an in-depth coverage of cutting edge technologies like Document/View Architecture, OLE, COM, DCOM, ActiveX, Open GL, Printing and Print Previewing, HTML Help System, Programming the disk and Screen Savers.