One of the major promises of Cairo is distributed computing--the ability to run components of your computing on other machines on the network. Object Linking and Embedding (OLE) is the key enabling technology, so it's fascinating to see early Remote OLE (ROLE) technology starting to appear from Microsoft. It doesn't have full-blown Cairo functionality, but it demonstrates the underlying concepts. And it's useful even in today's networked environment.
The Tools
Visual Basic 4 Enterprise Edition (VB4/EE) includes all the components of
ROLE. And other Microsoft tool sets will probably ship with ROLE functionality
in the future. Indeed, the correct place for ROLE is within the operating
system, 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 the libraries and dynamic link library (DLL) components you need to convert a machine from OLE to ROLE.
By far, the easiest way to set up a ROLE system is to follow the example you get with the VB4/EE package and its documentation. This example uses a simple OLE client application, named Hello/Client, which calls a simple server application, named Hello/Server. The server application returns a string to the client application when it's called, and the client displays the textual contents of that string. As OLE Automation goes, this setup approach is about as simple as it gets.
Installing and configuring ROLE isn't for the fainthearted. I had several aborted attempts trying to fly the system manually, and I would be astonished if anyone was fully successful without following the steps in the "Building Client 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 Automation clients and servers. And you can use whatever OLE client and server engines you want. But I'll use the Hello examples from the VB4/EE shrink-wrap to show you what's going on, and how it works under the hood.
The Server Side
The Hello/Server application is a simple VB4 OLE Automation server. It
returns a string that reads, "Hello Microsoft Visual Basic Users" when
an external client calls it by activating the Say Hello() function. In
other words, the client application creates an instance of the Hello/Server
application and fires off its SayHello method; the server then returns the
string to the client application.
Installing the server application is easy. However, you really need to use the supplied VB4 Setup Kit for the first server application, because the Setup Kit also copies all the necessary behind-the-scenes files for you. When you have run the Setup Kit on a server system once, you can just copy new server applications, as appropriate. As you see in figure 1, the VB4 Setup Kit lets you determine whether to install the application it builds, as an OLE Automation shared component or as a standard, stand-alone application.
Once you create the Setup Kit files, run the Setup Kit on the server--either over the network or via the installation floppy disks created during the setup process--to install the files there. Then, run the server application once to load all the Registry settings pertaining to OLE. You could manually install the type library if you want, but most users find it easier to just run the application once.
Next, start up the RACM application, and locate the name of the OLE Class that the server application exposes. (Running the application registers this name.) 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 starts several network-related services and then iconizes itself at the bottom of the screen.
So the process is to register the application on the server, tell RACM that the server application can be activated remotely, and then start the Automation Manager glue application.
The Client Side
On the client machine is a simple application named Hello/Client. It has an
on-form-load event that creates an object instance of the Hello/Server
application. On the Hello/Client main form is a single push-button. Pressing it
calls the SayHello method that the server exposed.
Nothing I've said so far should be surprising, by the way. This is standard OLE 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 is
to test it out locally in one computer before trying to make it work across the
network. So run the Hello/Server application on your client system to register
it in the Registry, just as you did on the server system.
Then, start the client application. On the screen, the client and server windows 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, so
the only changes you need to make are on the client side. Go to the RACM
application on the client, locate the HelloProj. HelloClass object, and
make 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 the protocol to use across the network for the connection. Ignore the Authentication Level combination box for now.
By setting these values, you tell the client where on the network it can find an instance of the Hello/Server object. The client now has a network address and a transport protocol, but it still needs to know that the Hello/Server application is no longer on the local hard disk. The client needs to 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 takes place immediately.
To test the change, fire up the Hello/Client application once more on the client. (The Hello/Server window doesn't appear on the client's desktop; it appears 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 correct textual information, as in figure 4.
Under the Hood
What's going on here? You started with a simple OLE server application and
installed 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 the
usual, standard OLE fashion. And by making a few changes to RACM, you enabled
the server application to run on a remote computer.
The critical point is that you don't change either the client or the server application at all to run remotely. Neither the server nor the client application knows that anything different is happening.
The methodology is simple. The OLE libraries in each computer are responsible for marshalling the OLE calls between applications. They present a standard interface across all the OLE applications. So inserting a network protocol into the middle of the OLE conversation is something you can do in the OLE layer, and the applications remain ignorant of it.
Registry Tricks
To understand the details, you must delve into the Registry database. It
contains 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 you have a backup copy of REG.DAT before proceeding. You're not going to edit the Registry directly, merely view it. But, believe me, you would hate to have your cat walk across the keyboard while REGEDT32 is running.
- Reset the server application on the client system for Local operation in RACM, and then start REGEDT32.
- Use the search command to locate a key called HelloProj.HelloClass. This key has just one entry: the Clsid value, which is a long hexadecimal number. This is the server application's unique identifying key, which you see in figure 5.
- Now, search for the hex number; as figure 6 shows, you should find an entry. Examine it carefully. One entry is called LocalServer32 on drive H; it is a local hard disk on the client system. Notice that the _NetworkAddress and _ProtocolSequence entries start with underscores (remember that the server is operating in Local mode at the moment).
- Close the Registry Editor, and return to RACM to switch the server key from Local to Remote. Start up REGEDT32 again, and search for the hex value once more. Notice that the NetworkAddress and ProtocolSequence entries no longer have underscores at the beginning of their names (the server is operating in Remote mode now), but the underscore is on the LocalServer32 entry, as you see in figure 7.
To know whether to work locally or remotely, all ROLE needs are these small changes to the Registry. It couldn't be simpler!
ROLE, as supplied in VB4/EE, works pretty well. However, it is completely untested so far in live production environments.
ROLE, as it stands now, has a few problems. You have to manually configure the client to tell it where to find the remote server. And, at the end of the day, that's a pretty unsatisfactory method, especially if you have hundreds of desktop computers.
Worse still, the client has no way to choose among multiple servers that are all providing the same OLE server service. So if the client is configured to use 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. Cairo
will bring a proper directory engine that knows where all the OLE components are
on the network. Instead of an OLE client application saying, "Please give
me a Real-time Dollar Feed on machine BigServer using NamedPipes," it will
just call, "Please give me a Real-time Dollar Feed," and let the Cairo
system find the server and do the behind-the-scenes work.
And because Cairo will replace the current passive OLE routing layer and Registry with distributed OLE and an active X.500-based directory server, a considerable number of your user settings and components will move off your computer and into a global repository. The X.500 directory engine will have to be very fast to handle OLE client/server connections from multiple clients to multiple servers, especially in a corporate environment using hundreds or thousands of workstations and dozens or hundreds of servers. And in the broad Windows NT future, there's no difference between a workstation and a server anyway.
But ROLE works, and you can satisfactorily use all those OLE applications out there that expose object methods and properties. Using a remote object server to supply the user interface for an in-place activated editing session is beyond ROLE at the moment, but this capability may come as faster network technologies appear.
Distributed OLE Works Now
I haven't discussed many of the details. Should you design your server
application to support multiple clients, or should you run multiple instances?
What will happen on the network with error reporting? And so on. But the bottom
line is this: A key component of Cairo, its distributed OLE functionality, is
here now--albeit in a hardwired and somewhat clunky implementation. It works,
and you'll want to consider implementing it today.
| Microsoft |
|
206-882-8080 Email: [email protected] Web: http://www.microsoft.com |
