Exploring Cairo: Remote OLE

One of the major promises of Cairo is distributed computing--the ability torun components of your computing on other machines on the network. ObjectLinking and Embedding (OLE) is the key enabling technology, so it's fascinatingto see early Remote OLE (ROLE) technology starting to appear from Microsoft. Itdoesn't have full-blown Cairo functionality, but it demonstrates the underlyingconcepts. And it's useful even in today's networked environment.

The Tools
Visual Basic 4 Enterprise Edition (VB4/EE) includes all the components ofROLE. And other Microsoft tool sets will probably ship with ROLE functionalityin the future. Indeed, the correct place for ROLE is within the operatingsystem, but that will have to wait until Cairo is completed and ready to roll.

In the VB4/EE package, you get a Remote Automation Connection Manager(RACM) tool, an Automation Manager application that runs as an icon, and all thelibraries and dynamic link library (DLL) components you need to convert amachine from OLE to ROLE.

By far, the easiest way to set up a ROLE system is to follow the exampleyou get with the VB4/EE package and its documentation. This example uses asimple OLE client application, named Hello/Client, which calls a simple serverapplication, named Hello/Server. The server application returns a string to theclient application when it's called, and the client displays the textualcontents of that string. As OLE Automation goes, this setup approach is about assimple as it gets.

Installing and configuring ROLE isn't for the fainthearted. I had severalaborted attempts trying to fly the system manually, and I would be astonished ifanyone was fully successful without following the steps in the "BuildingClient Server Applications with Visual Basic" book that comes with VB4/EE.

Suffice it to say, I'm not going to explain how VB4 creates OLE Automationclients and servers. And you can use whatever OLE client and server engines youwant. But I'll use the Hello examples from the VB4/EE shrink-wrap to show youwhat's going on, and how it works under the hood.

The Server Side
The Hello/Server application is a simple VB4 OLE Automation server. Itreturns a string that reads, "Hello Microsoft Visual Basic Users" whenan external client calls it by activating the Say Hello() function. Inother words, the client application creates an instance of the Hello/Serverapplication and fires off its SayHello method; the server then returns thestring to the client application.

Installing the server application is easy. However, you really need to usethe supplied VB4 Setup Kit for the first server application, because the SetupKit also copies all the necessary behind-the-scenes files for you. When you haverun the Setup Kit on a server system once, you can just copy new serverapplications, as appropriate. As you see in figure 1, the VB4 Setup Kit lets youdetermine whether to install the application it builds, as an OLE Automationshared component or as a standard, stand-alone application.

Once you create the Setup Kit files, run the Setup Kit on theserver--either over the network or via the installation floppy disks createdduring the setup process--to install the files there. Then, run the serverapplication once to load all the Registry settings pertaining to OLE. You couldmanually install the type library if you want, but most users find it easier tojust run the application once.

Next, start up the RACM application, and locate the name of the OLE Classthat the server application exposes. (Running the application registers thisname.) From the Client Access tab, set the Allow Remote Creates By Key value,and ensure that the Allow Remote Activation box is checked, as in figure 2.

Last, run the Automation Manager application. Once launched, it startsseveral network-related services and then iconizes itself at the bottom of thescreen.

So the process is to register the application on the server, tell RACM thatthe server application can be activated remotely, and then start the AutomationManager glue application.

The Client Side
On the client machine is a simple application named Hello/Client. It has anon-form-load event that creates an object instance of the Hello/Serverapplication. On the Hello/Client main form is a single push-button. Pressing itcalls the SayHello method that the server exposed.

Nothing I've said so far should be surprising, by the way. This is standardOLE Automation behavior, which is the key to making ROLE work.

Local Activation
To ensure that the client/server system is working correctly, a good idea isto test it out locally in one computer before trying to make it work across thenetwork. So run the Hello/Server application on your client system to registerit in the Registry, just as you did on the server system.

Then, start the client application. On the screen, the client and serverwindows appear. When you press the button, the message box appears, as in figure 3.

Remote Activation
Close the client and server applications. The server is ready for use, sothe only changes you need to make are on the client side. Go to the RACMapplication on the client, locate the HelloProj. HelloClass object, andmake sure that the Server Connection tab is selected.

This selection exposes some settings pertaining to network connections.Enter the name of the server into the Network Address box, and select theprotocol to use across the network for the connection. Ignore the AuthenticationLevel combination box for now.

By setting these values, you tell the client where on the network it canfind an instance of the Hello/Server object. The client now has a networkaddress and a transport protocol, but it still needs to know that theHello/Server application is no longer on the local hard disk. The client needsto find the network version on the network.

This change is easy. Click the right mouse button on the HelloProj entry,and select Remote instead of Local. The icon indicates the change, which takesplace immediately.

To test the change, fire up the Hello/Client application once more on theclient. (The Hello/Server window doesn't appear on the client's desktop; itappears on the server's desktop!) Press the button on the client application,and the message box will appear on the client desktop, filled with the correcttextual information, as in figure 4.

Under the Hood
What's going on here? You started with a simple OLE server application andinstalled it on a server system. You also installed it on a client system. Then,taking a simple OLE client application, you tested the local client copy in theusual, standard OLE fashion. And by making a few changes to RACM, you enabledthe server application to run on a remote computer.

The critical point is that you don't change either the client or the serverapplication at all to run remotely. Neither the server nor the clientapplication knows that anything different is happening.

The methodology is simple. The OLE libraries in each computer areresponsible for marshalling the OLE calls between applications. They present astandard interface across all the OLE applications. So inserting a networkprotocol into the middle of the OLE conversation is something you can do in theOLE layer, and the applications remain ignorant of it.

Registry Tricks
To understand the details, you must delve into the Registry database. Itcontains all the settings necessary to enable the OLE routing.

Let me insert a standard disclaimer here: The Registry Editor tool (REGEDT32.EXE) for viewing and editing the Registry is powerful, so make sure youhave a backup copy of REG.DAT before proceeding. You're not going to editthe Registry directly, merely view it. But, believe me, you would hate to haveyour cat walk across the keyboard while REGEDT32 is running.

To know whether to work locally or remotely, all ROLE needs are these smallchanges to the Registry. It couldn't be simpler!

ROLE, as supplied in VB4/EE, works pretty well. However, it iscompletely untested so far in live production environments.

ROLE, as it stands now, has a few problems. You have to manually configurethe client to tell it where to find the remote server. And, at the end of theday, that's a pretty unsatisfactory method, especially if you have hundreds ofdesktop computers.

Worse still, the client has no way to choose among multiple servers thatare all providing the same OLE server service. So if the client is configured touse server A, it will use server A--even if it's heavily loaded and server B,which has the same object, is lightly loaded.

On to Cairo
The current RACM solution is but a passing phase in ROLE development. Cairowill bring a proper directory engine that knows where all the OLE components areon the network. Instead of an OLE client application saying, "Please giveme a Real-time Dollar Feed on machine BigServer using NamedPipes," it willjust call, "Please give me a Real-time Dollar Feed," and let the Cairosystem find the server and do the behind-the-scenes work.

And because Cairo will replace the current passive OLE routing layer andRegistry with distributed OLE and an active X.500-based directory server, aconsiderable number of your user settings and components will move off yourcomputer and into a global repository. The X.500 directory engine will have tobe very fast to handle OLE client/server connections from multiple clients tomultiple servers, especially in a corporate environment using hundreds orthousands of workstations and dozens or hundreds of servers. And in the broadWindows NT future, there's no difference between a workstation and a serveranyway.

But ROLE works, and you can satisfactorily use all those OLE applicationsout there that expose object methods and properties. Using a remote objectserver to supply the user interface for an in-place activated editing session isbeyond ROLE at the moment, but this capability may come as faster networktechnologies appear.

Distributed OLE Works Now
I haven't discussed many of the details. Should you design your serverapplication to support multiple clients, or should you run multiple instances?What will happen on the network with error reporting? And so on. But the bottomline is this: A key component of Cairo, its distributed OLE functionality, ishere now--albeit in a hardwired and somewhat clunky implementation. It works,and you'll want to consider implementing it today.