| Stick an object on a network and assume that
applications will be able to use it. The idea is simple in
the broadest sense, but the devil is in the details. So
far, nobody has been able to come out with a standard way
of dealing with distributed components that addresses
enough of the problems and has enough support to take
hold. Two standards stand a chance. OLE may be the 800-pound gorilla of desktop-component technologies, but it's more of a rhesus monkey in the jungle of distributed components. To gain bulk, the upcoming Network OLE will use remote procedure calls (RPCs) to let companies scatter components throughout the enterprise and enable them to communicate. But there's already a gorilla in this territory: the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) standard. It tackles the same problems, but its object-request-broker (ORB) architecture gives developers greater programming-language and OS freedoms than OLE. And with technical roots that extend back to 1990, CORBA is a specification that's further along the evolutionary path. So which one is for you? Like all other complex questions, the answer is a hedge: It depends. But to make your decision, you need to understand how Network OLE and CORBA work. Network OLE Due in 1996-97 with the next version of Windows NT, Network OLE adds a third tier to your client/server network. It lets you encapsulate the critical code that contains your business rules into relatively lightweight components that you can distribute across the network as you see fit. For security, performance, or upgrading ease, you may locate the components on client systems, enterprise servers, or special component servers. Thus, the third tier can be more conceptual than a physical entity. A three-tier architecture requires a mechanism that keeps track of distributed components and lets clients access them. Network OLE has just such a feature. Network OLE is an OS layer that insulates applications and components from the hairy details of network transports and component tracking. If it works as Microsoft is promising, it will be transparent to users and translucent to network administrators. Users won't need to know whether the OLE objects they're using reside on their local machines or on other networked systems. Administrators will decide where to install the objects, and Network OLE will maintain the invisible links even if the administrator moves or updates the objects (see "Extending the Reach of OLE," November 1994 BYTE). Priming the Pump Microsoft is doing two things to pave the way for Network OLE. First, it is urging software developers to support OLE 2.0 in all new software. The more OLE 2.0 features that programs support, the more benefits they'll automatically inherit under Network OLE. Second, Microsoft is offering a glimpse of what's to come. A new remote automation mechanism in Visual Basic 4.0 (VB4) Enterprise Edition lets you build and deploy distributable objects (they're called OLE automation servers). You can scatter these objects across a network and call their methods from any client application that's an OLE automation controller. Some examples of OLE automation controllers are Microsoft's Word, Excel, Access, PowerPoint, and VB4; Borland's Visual dBase and Paradox for Windows; Novell's Quattro Pro; and Powersoft's PowerBuilder. Until now, the only way you could use OLE over a network was to dynamically link or embed OLE objects in your applications. In other words, you could manually embed an Excel chart in a Word document if Word was on the client machine and Excel was on a file server, but you couldn't write a Word macro that called Excel's OLE methods on the file server. VB4 provides the remote automation mechanism that lets the OLE controller application call the remote OLE object's automation methods programmatically. For example, today you could write a VB program that sends 10 values to a copy of Excel on the same computer and ask Excel to compute and return the sum of those values. But you can't do that if the copies of VB and Excel are on different machines on a network. With VB4 remote automation, you can. Remote automation uses a new OLE proxy on the client machine and a remote automation manager on the server (which could be a traditional server, another client machine, or a component server). When a client application calls the methods of an OLE automation object, it first checks the OLE object registry (see the figure "Stepping Stone to Network OLE"). The registry knows whether the called object is on a local machine or a remote machine. If the object is on a local machine, the request passes through the regular OLE proxy to the object. If the called object is remote, the new OLE proxy handles the request. It translates the OLE call into a Windows NT-standard RPC and sends it over the network to the server. At that end, the remote automation manager translates the RPC back into a regular OLE call and forwards it to the OLE object. OLE callbacks are handled the same way. It's not quite as cool as full-blown Network OLE, but it's enough to whet your appetite. Network OLE will be more robust and will offer many more features. For example, it will work with the NT file system to automatically keep track of objects if you relocate them on the network. It will also let you link applications and objects created with any development tools, not just VB4. (Technically, VB4 makes this possible, but Microsoft's licensing agreement requires that one of the OLE objects must be VB or created with VB.) The advantages of a three-tier architecture will become more obvious as the technology becomes more widespread. By delivering a preview of Network OLE in VB4 — and by laying the groundwork with OLE 2.0 in today's software — Microsoft is building a solid distributed-objects strategy for the future. Technology Tango Network OLE isn't the only technology to consider. The OMG recently released CORBA 2.0, a revision of the original CORBA specifications. But what happens to CORBA in the next year — especially how the standard evolves to enhance portability and interoperability — could hold the key to the future of componentware. ORBs are the cornerstones of the CORBA architecture. In a distributed environment, they provide a common platform for objects to request data and services on the client side and for servers to send their responses back to the client objects (see the figure "Objects in Orbit"). ORBs hide interoperability details from the client and server objects, so such issues as what programming language and OS each object uses don't stand in the way of their communication. Thanks to ORBs, a client object doesn't even need to know the location of its server counterpart, which may be on the same machine or on a computer thousands of miles away. It's the ORB's job to be the matchmaker. A client application makes a request for some kind of information. The request has two basic parts: an object reference for a particular object and the action the object is to perform. The client creates this request by calling stub routines specific to an object (through the interface definition language, or IDL, interface) or by constructing the request dynamically. Either way, the client sees the same interface regardless of what language the object is written in or where it lives on the network. The stub routine (or dynamic request) routes the request to the ORB. The ORB is responsible for maintaining mechanisms to find the requested object, preparing the object to receive the request, and communicating the data inside the request. During the request, the ORB locates the appropriate object implementation, transmits the parameters of the request, and transfers control to the object. Once the object is done with the request, it passes control back to the ORB along with the results. The ORB then passes control back to the client application. CORBA 2.0 built on this architecture and addressed some of the shortcomings in the original version. Specifically, it includes bridging technology, which provides for communication between ORBs, and an optional Distributed Computing Environment-based (DCE) interoperability scheme. CORBA 2.0 also adopted TCP/IP as the standard communications protocol to help ensure out-of-the-box interoperability between different vendors' TCP/IP implementations of CORBA. The DCE can also be used as a way for objects to communicate, but it is an option that users must choose to implement. These enhancements extend the portability and interoperability of the standard. CORBA is part of the larger Object Management Architecture (OMA), which includes CORBAservices and CORBAfacilities. CORBAservices provide basic operations, such as object class management, instance management, and security. CORBAfacilities offer link management, print services, and E-mail. Such facilities will help extend the portability of CORBA into such areas as groupware and transaction monitors. In some ways, what is happening to CORBA is analogous to what has happened to network OSes (NOSes) in recent years. When they were introduced, many NOSes offered such basic services as print and file services. But for those NOSes that moved from being aimed at the workgroup to being honed for the enterprise network, developers added more capabilities, such as directory and security services. In a similar way, the OMG has added services to CORBA and expanded the ways users access them. For example, the proposed licensing service lets a CORBA developer use the Object Licensing Service for monitoring and possibly metering an object's usage. This lets users write a program that tracks an object's usage and bills customers based on the number of times they accessed an object and how long an object was used each time. Such a service goes beyond the basic functional interoperability that is required in object-oriented applications development. Looking Ahead Back to the jungle. For better or worse, OLE is the object technology that dominates most desktop-development efforts today. As Microsoft extends OLE's reach into a distributed environment, the combination of the client stranglehold with strong network services could create an insurmountable mountain for CORBA. A possible compromise scenario is an object-development environment, where the desktop is dominated by OLE and the backbone is CORBA. Ideally, there would be a simple way to link the Windows desktop with objects residing on Unix and OS/2 servers. Today, companies such as Expersoft (San Diego), Iona Technologies (Dublin, Ireland), Genesis Development (West Chester, PA), and Visual Edge Software (Montreal) offer products designed to bridge the OLE-to-CORBA gap. However, all these solutions are proprietary. The OMG is working on an OLE/CORBA specification that would standardize the process in which a user would be able to carry out an operation on a CORBA object from OLE-enabled applications. Last summer, the OMG received over a dozen vendor proposals on how to close the OLE-to-CORBA link. Basically, the OMG's efforts could lead to the definition of an OLE/COM (Component Object Model)-to-CORBA gateway that provides a mapping between COM and OMA. In the meantime, developers are left to watch the standards evolve and to bet development resources on a large gorilla or a committee-designed camel. WHERE TO FINDMicrosoft Corp.Stepping Stone to Network OLE Objects in Orbit Tom R. Halfhill is a senior editor for BYTE in San Mateo, California, and Salvatore Salamone is a news editor for BYTE in New York. They can be reached on the Internet or BIX at thalfhill@bix.com and ssalamone@bix.com. Copyright 1994-1998 BYTE |