It's a crazy, mixed-up world out there; Windows 95 runs on millions of desktops, and Windows NT runs on more application and database servers than ever. Visual Basic 4.0, PowerBuilder 5.0, and Delphi 2.0 (Delphi32) rest in the hands of legions of client/ server developers. (PowerBuilder 5.0 and Delphi 2.0 are in beta at press time -- there is potential for these products to reach millions, but these versions are not there yet.) What do all these products have in common? The answer is OLE automation.
OLE automation provides a common application infrastructure that lets client/server developers bind several applications together easily. This lets each application use the services of the others, but the advantages of using OLE automation don't stop the re. Remote OLE automation can now reach across networks as well, letting developers create multi-tiered client/server applications using OLE as the plumbing and wiring.
Although OLE has been in Microsoft applications and operating systems for years, OLE automation has been impractical for client/server developers until the recent development of certain OLE automation tools. As Microsoft's distributed OLE looms near with even more distributed object capabilities, remote OLE automation could be the best way to build three-tier client/server applications because you won't have to commit to proprietary technology. That is, if you believe that Microsoft standards aren't pro prietary.
Let's look at what OLE automation can do for you, and if you've ignored OLE so far, why I think you need to begin paying attention.
The standard interface is the key to successful OLE automation. OLE provides a standard object interface that application vendors use to expose any application-specific functions useable by other applications. In other words, an application that supports OLE automation will let other applications know what it can do for them and provide an interface access to these capabilities.
There are two parts to OLE automation: the OLE automation controller and the OLE automation server. The OLE automation controller is the client side of OLE automation and actually invokes the services of an OLE automation server using the common OLE obje ct interface. On the other hand, OLE automation servers have exposed functions or methods available for use by the OLE automation controller. For example, Microsoft Access (functioning as an OLE automation controller) can invoke Microsoft Excel (acting a s an OLE automation server) to analyze and chart data from an Access application. Excel, like other OLE-enabled applications (and like most of the Microsoft office automation and development products) can act as both a server and a controller.
There are two types of OLE automation servers: in-process and out-of-process. In-process servers are usually .dlls, and they execute in the same memory and process space as their clients. Out-of-process servers (sometimes called local servers) execute in a separate memory and process space from their clients. Out-of-process servers are usually .exes, and they communicate with the OLE automation controllers using Microsoft's lightweight remote procedure call (LRPC) mechanism. Using the LRPC mechanism, OL E automation controllers can even invoke the services of an OLE automation server over a network. The process is similar to invoking a process on an application server using a standard RPC. The application makes a local call that executes on a remote ser ver. As with most client/server RPC models, the client application needs to establish a session on that server using a user ID and password. This is really another type of out-of-process OLE automation server known as a remote OLE automation server. More on this later.
Behind the scenes, OLE automation servers implement a specific interface known as IDispatch. IDispatch provides the mechanism by which an object can expose its capabilities, such as incoming and outgoing methods. These functions are known as "dispinterfa ces," which is short for dispatch interfaces. To invoke a certain dispinterface, the client (OLE automation controller) calls a single function, IDispatch::Invoke, and passes a dispatch identifier that points to a specific method or property on the OLE s erver.
The dispatch identifiers are generated by OLE's Object Description Language (ODL). Clients must discover at runtime which interfaces an automation server provides. Clients can obtain all of this information at runtime from Type Libraries or OLE's interfa ce repositories. The ODL defines the interface that an OLE object supports and is commensurate with CORBA's (Common Object Request Broker Architecture's) IDL (Interface Definition Language).
If all this sounds a bit complex to you, you're not alone. Understanding the OLE interfaces and developing OLE-compliant applications are not easy tasks. For instance, my first experience creating an OLE automation server was frustrating. Fortunately, th ere are plenty of OLE-enabled development tools (such as Visual Basic 4.0, PowerBuilder 5.0, Delphi 2.0, and others) out there that hide the complexities of creating and using OLE automation servers. If you want to use OLE automation for your client/serv er application, these tools are your best bet. Let's look specifically at how Visual Basic 4.0 and Delphi 2.0 support OLE automation, local and remote.
Remote OLE automation servers let you run an OLE server on one machine and your controller on another. The server and the controller communicate with one another using the LRPCs over a network. (See Figure 1.) The beauty of remote OLE automation is that neither the controller nor the server knows that the connection with the other object exists as a link across a network. A remote OLE automation server appears as if it's running locally as a run-of-the-mill, out-of-process server.
If you're thinking application partitioning, you're right. Remote OLE automation servers provide developers with the ability to run one logical application divided among several processors. For instance, a single client/server application may be made up of many OLE automation servers running locally, or running on other Windows 95- or Windows NT-based computers connected by a network. Using this three-tier (really multi-tier or n-tier) client/server development model, remote OLE automation provides bett er scalability and performance and the centralization of application maintenance activities. Performance improves because OLE is able to allocate the processing load among several computers, thus processing an application in parallel. This is the same id ea behind application partitioning tools such as Forté and Dynasty. Increased network traffic isn't a concern, because you are sending lightweight RPCs across the network and they don't require much bandwidth.
Another benefit of using OLE automation servers is their ability to operate asynchronously. This allows OLE automation controller applications that invoke a procedure on an OLE automation server to continue processing even though the procedure is not com plete. The server notifies the controller application through a message when the procedure is finished. For example, a Visual C++ application could invoke a procedure on an OLE automation server created with Visual Basic to print a large sales report. Be cause printing some reports can take a lot of time, and the developer does not want to tie up the user, the developer can invoke the procedure as an asynchronous process. This means that the user can continue using the application after invoking the repo rting process. When the report is complete the client application is notified through a message.
The ability to create and share remote OLE automation servers also allows developers to place application processing (that is, business rules) on a central application server. As with other three-tier solutions, such as TP monitors, updating the applicat ion is just a matter of changing the logic on a single shared remote OLE automation server. The new logic is propagated automatically to all client applications that invoke services on the central server object. OLE automation servers, however, don't pro vide the same degree of transaction management power as TP monitors. For now, you'll have to build those capabilities into your OLE automation server by hand (an example is an application that processes transactions as they are received by the system, ot herwise known as online or realtime processing).
Remote OLE automation servers bring easy application partitioning capabilities to OLE-compliant development tools. However, unlike other tools that support application partitioning, such as Forté and Dynasty, the OLE automation mechanism is not as proprietary. You can mix and match many third-party OLE automation servers to meet the requirements of your client/server application. Like proprietary partitioning tools, OLE automation provides the developer with the ability to dynamically partition a pplications as processing and application requirements change over time. For instance, when the processing load increases, developers can simply distribute OLE automation processing among additional servers. OLE is still a Microsoft-only phenomenon, and only Microsoft operating systems (Windows 95 and Windows NT) are supported. However, support for Unix is forthcoming, and it will be part of DEC's Object Broker.
Also keep in mind that remote OLE automation has a "glide path" to the distributed OLE capabilities slated for Microsoft's Cairo operating system, due out sometime in 1996. Distributed OLE is a network version of Microsoft's proprietary object architectu re that allows chunks of prewritten, reuseable code to be shared among thousands of computers across a network. Remote OLE automation only provides a subset of features for distributed OLE that will be built right into the operating system. Distributed O LE, however, is still alpha.
As an OLE automation controller, Delphi can use a single variable to connect to various OLE automation servers (Delphi and third-party servers) during the execution of a Delphi application. Moreover, Delphi provides the ability to use named parameters wh en making calls to OLE automation servers (this is unique to Delphi).
Developers can also create both in-process and out-of-process OLE automation servers using Delphi. To create a new OLE automation server, the Delphi developer needs to define an object that inherits from a type called TAutoObject. Having done this, it's just a matter of defining a section of code with a new automated reserved word to expose properties and methods you want to make available to other OLE automation controller applications. The visibility of an identifier declared is the same as a public i dentifier, and developers can expose properties, parameters, and function results using many available types. From here you can either create an in-process automation server (.dll) or an out-of-process OLE automation server (.exe).
Delphi includes an expert that makes it easier to manage the creation of OLE automation servers. This mechanism automatically manages the parameters for the registration call, such as the Program ID, the Class ID, and instancing options.
The real strength of Visual Basic is its ability to easily create remote OLE automation servers using standard Visual Basic development procedures. (See Figure 3.) Visual Basic remote OLE automation servers can communicate over man y protocols, including TCP/IP, NetBEUI, IPX/SPX, and Named Pipes. Any OLE application can pass an object reference to any remote OLE automation server on a computer connected by a network. (For more information on creating remote OLE automation servers w ith Visual Basic, see my article, "Visual Basic 4.0: Ready for the Enterprise?" DBMS, January 1996, page 44.)
In addition to the ability to create and invoke remote OLE automation servers, Visual Basic also provides an OLE server management infrastructure. Visual Basic contains a pool manager that gives you the ability to build pools of OLE automation objects an d distribute them to clients. The pool manager can optimize network performance by looking for and eliminating bottlenecks. Visual Basic also provides an automation manager to watch LRPCs as they move to and from remote OLE automation servers.
Of course, Visual Basic and Delphi are only a few of the tools that offer or will offer support for OLE automation. Most of the client/server tools I've tested in the last year provide or have announced support for OLE automation. Most of those will also support remote OLE automation shortly.
OLE, however, is not the only game in town. The CORBA crowd continues to push OpenDoc and other CORBA-compliant distributed objects. Although CORBA provides many of the same features as OLE, and offers a better interface and wider operating system suppor t, CORBA has not yet won over most tool vendors and developers. In fact, by the time this column hits the newsstand, OLE will have won the battle for the desktop. As with the OS/2 Warp vs. Windows 95 battle, the best technology doesn't always win.
What does this mean to you? The bottom line is that OLE is no longer an elective. It's a required course for those who want to graduate into the new world of distributed client/server computing.
