Key Information You Should Consider Before Including Distributed Objects in Your Strategy.
(Including a list of commonly used acronyms)
Slowly but surely, distributed objects continue to make their way into the world of client/server. In the early '90s, what was supposed to be a revolution turned out to be an evolution of specifications and trial balloons. Today, however, we could be on the verge of moving mainstream client/server development into the world of distributed objects, and the Web could be the way to get there.
Other issues that could move developers toward distributed objects include Microsoft's Distributed Component Object Model (DCOM) and its ActiveX (formally OCX) component incarnation. With Windows NT 4.0 already DCOM-ready and Windows 95 heading there quickly, developers may find that their object request broker (ORB) infrastructure is part of the operating system. Existing OLE-enabled tools are ready to take advantage of the Microsoft giveaway ORB.
Components are part of the game as well. Because OpenDoc did not appear on the desktop as predicted with the poor sales of Macintoshes and OS/2, ActiveX wants to be your component of choice for both client/server and the Web. OpenDoc is a component of IBM's Distributed System Object Model (DSOM), which adheres to the Common Object Request Broker Architecture (CORBA).
There are tough decisions in your future, so let's start from the beginning. In this article I look at the concept behind distributed objects, as well as the standards that now compete for the hearts and minds of developers and tool vendors. I examine components and their links to distributed object standards, and then I wrap things up with a look at how distributed objects are changing the Web.
The concept of an ORB grew out of the early days of object-oriented development. As developers learned to leverage objects within applications, they looked to mix and match objects with other applications as well. Because objects are tool-dependent (such as C++, Smalltalk, and PowerBuilder), they don't work and play well with others. Developers needed a binary object standard that would let them mix and match language-independent objects.
In their spare time, ORBs pass requests from clients to object implementations on which they are invoked. The client makes the request using the ORB Core through the Interface Definition Language (IDL) stub or through the Dynamic Invocation Interface (DII). The stub provides the mapping between the language of choice (such as C++ or Smalltalk). The ORB has to support the mapping. The ORB Core can then transfer the request to the object implementation that receives the message through an up-call using an IDL skeleton or dynamic skeleton.
In 1989, the Object Management Group (OMG), a consortium of technology vendors including IBM Corp., Apple Computer Inc., and Sun Microsystems Inc., mobilized to create a cross-compatible distributed object standard. The promise was clear: object reuse regardless of the platform or programming language. The goal was a common binary object with methods and data that work using all types of development environments on all types of platforms.
OMG was not, and is not, a product company: It is in the specification business. Using a committee of organizations, each with its own agenda, OMG set out to create the first CORBA standard, which appeared around 1991. CORBA is a specification document that describes a messaging facility for distributed object environments to provide a standard mechanism for objects to invoke each other's services.
The original CORBA specification (CORBA 1.1) consisted of two parts: the IDL and the DII. Each service exists inside the ORB and the base services form to enable messaging between objects inside a local or distributed system.
The IDL is really just an object structure that gives developers an API to access the object services while the objects are up and running. The IDL lets you build applications while at the same time understanding the types of objects with which you can communicate when an ORB-based application is up and running. DII is also an API that gives you dynamic construction of object invocations. You don't have to call a routine to invoke an operation inside a particular object. The client can set up the objects and operations, including any parameters. With DII, you can make decisions while the objects are running. IDL requires that you set things up beforehand. Many commercial ORBs resulted from CORBA 1.1, including IBM's DSOM, Visigenic Software Inc.'s VisiBroker for C++ (formerly ORBeline from PostModern Computing Technologies), and Iona's Orbix, to name just a few. Although CORBA 1.1 was a step in the right direction, it did not provide enough detail for tool vendors and developers to create objects that work together. For example, DSOM could not work with Orbix out of the box. So the OMG began work on another CORBA specification, CORBA 2.0. As OMG President Chris Stone put it to me a few years ago, "CORBA 1.1 solved the problem of portability; CORBA 2.0 adds interoperability." CORBA 2.0 was released in 1994.
The basic difference between CORBA 1.1 and 2.0 is the addition of specific syntax for a network protocol; the IDL remains largely the same. CORBA 2.0 also provides mapping to C++ and Smalltalk, which rose in popularity after the original specification's release. In addition, CORBA 2.0 defines a TCP/IP-based Inter-ORB backbone, as well as an Inter-ORB communication service that enables components to generate universal global IDs for their interface.
As I alluded to already, an ORB is an engine that can communicate with other local or remote objects using a well-defined common interface and line protocol. ORBs make requests to other ORBs (using the same standards, such as DCOM and CORBA) and process responses. The power of ORBs is that all of these communications and method invocations take place away from the eye of the user. The applications are built on top of the ORBs, and the ORBs carry on business in the background automatically. The concept is to ensure the application of portability and interoperability, either locally or across a network. The CORBA specification simply defines how these ORBs work together.
Object Services are groups of services that use an object interface to communicate from one service to the next. Object services provide base services such as security, transaction management, and data exchange. Using this base set of services, developers can build other services on top of them. Object Services are mandated by CORBA.
Common Facilities are collections of services as well, but they relate more to a client than a server. You'll see what Common Facilities can do by looking at component document facilities such as OpenDoc. Common Facilities are optional CORBA services.
Application Objects are objects that support the application directly. These objects are defined by the developer, and they are the portions of CORBA that actually solve the business problem at hand. These are the facilities that are built using the IDL. The IDL assures that they can communicate with other CORBA-compliant ORBs.
As OLE automation became a standard on Windows desktops, client/server tools such as Delphi, Visual Basic, Visual C++, and PowerBuilder began to support COM by giving developers the ability to create OLE automation servers.
OLE automation servers come in two flavors: in-process and out-of-process. In-process OLE automation servers are really just DLLs loaded directly into the memory space of the application to provide all sorts of application functionality. ActiveX controls are examples of in-process OLE automation servers that act like components.
Out-of-process OLE automation servers are ORBs that function outside the application's memory space. Out-of-process OLE automation servers are .exes, and they run in the multi-tasking environments of Windows 95 and Windows NT. Out-of-process servers communicate with other OLE-enabled ORBs or applications using a remote procedure call (RPC) mechanism and the standard OLE interface. Until just a few months ago, however, COM could not leverage the power of distributed objects. With the release of Windows NT 4.0, DCOM is now a reality for Windows-oriented client/server developers.
DCOM lets COM-enabled (OLE-enabled) application-development tools and even office-automation applications access out-of-process OLE automation servers that physically exist on the local machine or on a machine connected by a network. (See Figure 2.) The application simply checks with the Windows NT registry to locate the remote ORB, and then it invokes its services. For example, you could create a COM ORB using any number of tools that automatically generate a sales report if a certain method in the ORB is invoked. Other COM-enabled applications existing on the network can access that object by locating and invoking its methods through the DCOM mechanism built into the Windows operating system.
DCOM is very different from CORBA because it is built into the infrastructure of the operating system and network, and it is not delivered by an ORB vendor. For existing Windows 95 (where it's soon to be included) and Windows NT shops, this means that it's already there. What's more, although CORBA has yet to attract the mainstream tool market, COM is already a part of most development tools you purchase for Windows. However, DCOM is a Windows-only phenomenon, and those of you who run a hodgepodge of operating systems and processors won't find any value in DCOM.
For instance, say you need to create an application to support a banking system. The application needs to include a loan-processing system, an investment system, and a system to support new accounts. Rather than create standalone applications to solve each problem using any number of client/server development tools, you can take an open ORB approach.
Leveraging ORBs, you can create each application by building it as an ORB (or usually a group of ORBs, but for this example let's keep things simple). Creating the Loan Processing System as an ORB is just a matter of defining the application logic inside the ORB using the IDL in the case of CORBA, or the object definition language (ODL) in the case of COM. You can even connect the ORB to a database server if you need data (and you usually do). Once created, the ORB can run anywhere on the network and will be accessible by any application interface that's ORB-aware (for instance, IBM VisualAge or even Powersoft PowerBuilder 5.0). The power of such an architecture is that, because the ORB is accessible by any application running on the network, the logic is centrally located. Developers can change the ORB at any time for any reason, automatically changing the functionality of the applications that use it. ORBs are tool-independent as well, and all sorts of applications can access the services of the banking ORBs. This lets you reuse the ORBs' application services throughout the application.
Because the ORBs run remotely, the client does not get burdened with the application processing (as is the case with traditional two-tier "fat client" client/server development). ORBs become an application service layer comparable to transaction-processing (TP) monitors. Moreover, because the ORBs are portable, you can move them from platform to platform without worrying about interoperability with other platforms (all except the Windows-bound COM).
ActiveX is COM's answer to components and to Java. ActiveX is really just a warmed-over version of OCX that has been revamped for use inside Web browsers such as Microsoft's Internet Explorer, thus providing an alternative to Java. You'll also find ActiveX components in ActiveX documents, running on ActiveX-enabled servers such as Microsoft Internet Information Server and Microsoft's upcoming Viper TP monitor. ActiveX components can also encapsulate Java applets.
Client/server developers embed ActiveX components inside ActiveX-enabled client/server development tools such as Visual Basic, PowerBuilder, and Delphi. The power of ActiveX is not in its architecture and its links to COM, but rather in the wide array of tools that support ActiveX. For example, you can create ActiveX components with any number of tools for any number of tools and applications. Tool support is the key to the acceptance of any standard.
The downside of ActiveX is its proprietary links to Microsoft and the Windows operating systems. Microsoft will address the industry's claim that ActiveX is a Microsoft proprietary standard by giving the standard away to an independent organization made up of member organizations, including Microsoft, to direct the future of ActiveX. Microsoft also plans to port ActiveX to other platforms. Microsoft is working with Metrowerks Corp. (Austin, Texas) to support ActiveX on the Macintosh, and with Bristol Technology Inc. and Mainsoft Corp. to support ActiveX on Unix platforms. Clearly Microsoft's goal is to provide a multiplatform component standard that competes directly with OpenDoc and Java.
If you listen to Netscape, IIOP is the new protocol for the Web, replacing HTTP as the standard method of Web communications. With over 20 million Netscape browsers in use today, Netscape brings life to an almost nonexistent distributed objects marketplace. IIOP allows ORBs that reside on a client running inside a browser to communicate with any other CORBA-compliant object running on an Intranet or the Internet. (For more on this subject, see my column in the January Internet Systems.) ORB vendors such as Visigenic are creating CORBA-compliant ORBs specifically for the Web. Visigenic licensed its VisiBroker Java-enabled ORB to Netscape. With the release of Netscape Communicator (formally Navigator) 4.0, millions of Web users will finally understand the power of distributed objects -- that is, if this isn't all just hype.
DCOM and Microsoft are taking the same route, but they are both a bit behind CORBA and Netscape. In a May 1996 press release, Microsoft described ActiveX's answer to IIOP. Using a DCOM-based binary network protocol, Microsoft hopes to link all ActiveX objects through the Internet and Intranets using a DCE-RPC-enabled communication protocol. This is all just talk for now, but by the end of 1997 we could see DCOM extend itself to the Web by riding on top of the popularity of ActiveX.
In addition, ORBs remain largely tied to synchronous communications middleware. Missing is support for message-oriented middleware that can operate asynchronously. What's more, the server code is not as portable as it should be. These issues are true for both DCOM- and CORBA-based ORBs.
The new generation of distributed objects are supposed to fix all of these problems. However, products that use them are slow to appear. The best hope for distributed objects is the Web. Hype is driving legions of people to the Web, and users are demanding new, more advanced means by which to deploy applications. Distributed objects will shine on the Web, and that could be the break we're waiting for.
Figure 1.
--The CORBA ORB provides four main components: the object request broker (ORB), object services, common facilities, and application objects.
| Commonly Used Acronyms | |
|---|---|
| COM | Component Object Model |
| CORBA | Common Object Request Broker Architecture |
| DCOM | Distributed Component Object Model |
| DII | Dynamic Invocation Interface |
| DSOM | Distributed System Object Model |
| IDL | Interface Definition Language |
| IIOP | Internet Inter-ORB Protocol |
| ODL | Object Definition Language |
| OMG | Object Management Group |
| ORB | Object Request Broker |
| RPC | Remote Procedure Call |
