Standardization Efforts in the Area of Distributed Objects
by
Mike Schup
April 17, 1998
Table of Contents
- What are Distributed Objects?
- The Standardization Effort
- The Major Players, Architectures, and Technologies
- The Object Management Group (CORBA/IIOP)
- Microsoft Corporation (COM)
- Sun Microsystems (Java)
- The Present and Future of Distributed Objects
- Acronym Key
- References
Background on Distributed Computing
Prior to understanding what distributed objects are, one must have at least a decent handle on the area of distributed computing. The term "Distributed Computing" simply refers to operations that run on widely separated computers that are connected via a network. The ATM is a common example of a distributed environment. The computer in the ATM, a server at the ATM's home bank, your own bank's server, and the network that connects these components all work together to deliver your cash to you in a matter of minutes. In the past, most distributed applications such as the ATM have been proprietary. Recently, however, distributed applications have become a possibility in the PC environment.
During the 1990's, increased power in the PC/server environment and widespread connectivity via the internet have led to a "network-centric" way of computing (Orchard, 32). The challenge for application developers is that the architecture in which they program is changing once again. Applications in the network world focus on the use of program-to-program communications (called function integration) more than the data transfer or direct data access mechanisms of the past. We are also seeing a shift from a more traditional two-tier client/server architecture to a three-tier architecture, also known as the Network Computing Architecture (see figure 1). According to the Gardner Group, ninety percent of all new client/server applications will be multitier (three or more tiers) in 2001, up from 40 percent in 1996 (Schulte, 2).
In order to make the shift to multitier applications a reality and to be able to create powerful distributed applications in terms of performance and scalability, it will take still more computing power, increased bandwidth, and standards. The standards are taking shape in three main areas: distributed objects, transaction processing, and directory services. This paper attempts to tackle the first area, distributed objects, in terms of what they are, how they are being standardized, who the major players are in the standardization effort, and finally, where distributed objects may be headed down the road.
As software becomes larger and more complicated, it becomes more and more desirable to break applications down into smaller pieces. Component software development applies the principals of modularity and encapsulation in order to break applications down into multiple, finer-grained programs (or groups of programs), called software components. These components are dynamically bindable packages of one or more programs managed as a 'black box' of sorts and accessed through documented interfaces discovered at runtime. A fundamental part of distributed processing exists at the layer in which these components communicate, or call each other. In the past, we've used remote procedure calls (RPCs) or other forms of middleware which enable remote calls in a general-purpose, cross-platform manner. RPCs also support encapsulation and modularity, but they lack a way to formally manage the interfaces.
Object orientation enters into the picture in the form of distributed objects and Object Request Brokers (ORBs). Distributed objects are simply objects that exist at the system level and can be accessed remotely. They can interact with other objects elsewhere in the system and elsewhere on the network. They can query other objects' capabilities or inherit them for their own use. Software components can invoke methods on remote distributed objects nearly as easily as they can on a local object. Thus, distributed objects extend RPCs by allowing methods to be called on a fine-grained object, rather than a course-grained stateless server (Orchard, 32).
ORBs are a special kind of program-to-program middleware that is capable of supporting an object-based programming style. They are the mechanism that allows methods to be called on remote objects. Two characteristics separate ORBs from other middleware: formal, dynamic interface management and explicit component uniqueness (Schulte, 12). The first difference is that an ORB maintains or has access to repositories and directories that enable it to formally manage various aspects of Application Program Interfaces (APIs). By relying on the repositories, this allows certain decisions regarding how the programs will communicate to be deferred until runtime. The repositories hold details including the names of supported operations and their associated parameter lists, along with the data types of each input and output parameter. The second difference as stated above is the idea of explicit component uniqueness. This means that an ORB has the ability to specify exactly what thing (or object) is the subject of the operation. The ORB does this by passing to the client a unique identifier for an instance of a server object. The client then uses the unique identifier to communicate with the server component. In addition, the client can pass the identifier on to other clients, thus giving them the ability to work with the same exact instance of the server component. Both of these characteristics that are unique to ORBs make it easier to apply object-related concepts to components.
Next we will look at the details of a remote object method call in a distributed object system. The syntax of the call is the same as if we were calling on local object methods, however figure 2 shows the actual data path necessary in handling the remote object call.
- The client invokes a method call to a client proxy.
- The client proxy organizes the input object parameters into a platform-independent byte stream suitable for transport.
- The Object broker on the client side surveys the network to find the remote object broker that has the particular remote object in its registry. Then the client object broker passes the object ID, the method to be called, and the transport bytes to the remote object broker.
- The remote object broker connects to the desired remote object via a server proxy. Then it passes the transport bytes on to the server proxy.
- The server proxy transforms the transport bytes back into object parameters and then makes the call to the requested method.
- Once the method is done executing, the results can be passed back to the client application in a similar manner.
With the background in distributed computing in place, we will now look at the standardization efforts in this area. The ORB, as described above, plays the central role in making distributed applications work. This is because ORBs provide standardized interfaces through which program components can communicate while hiding details such as the OS and network hardware from the programmer and end user. For this reason, ORBs are the center of attention in the standardization effort.
The Major Players, Architectures, and Technologies
The major players in the arena and their respective architectures and technologies are listed in table 1. Each player, architecture, and technology will be described along with some remarks on each player's role in the standardization effort.
Table 1: Major Players, Architectures, and Technologies
| Player | Architecture | Network Object Model Technology |
| Object Management Group (OMG) | OMA (Object Management Architecture) | CORBA/IIOP (Common Object Request Broker Architecture/Internet Inter-ORB Protocol) |
| Microsoft | Windows DNA (Distributed interNet
Applications Architecture)
|
COM/DCOM (Distributed Common Object Model), ActiveX |
| Sun Microsystems | Enterprise JavaBean Architecture | Java RMI (Remote Method Invocation), JavaBeans |
The Object Management Group (CORBA/IIOP)
The Object Management Group (OMG) is a consortia established in 1989 with the mission to "promote the theory and practice of object technology for the development of distributed computing systems" (OMG website). Today, OMG is the world's largest software consortium, consisting of over 800 members including software vendors, software developers, and end-users. OMG's goal is to provide a standard architectural framework for the interaction of objects in a heterogeneous environment. In particular, it aims to reduce the complexity, lower the costs, and expedite the introduction of new software applications.
OMG pursues its goals by creating standards. They do not produce software or implementation guidelines. OMG puts together specifications utilizing ideas of its members who respond to Requests For Information (RFI) and Requests For Proposals (RFP). One benefit of this approach comes from the fact that most of the major software companies interested in distributed object oriented development are among OMG members. This can also be a disadvantage, however, because each of these companies can have their own agendas and their own pocketbooks to protect.
To create a framework for producing specifications, the OMG laid out a reference architecture called the Object Management Architecture (OMA). OMA is a high-level vision of a complete distributed environment. Specifically, the reference model identifies and characterizes components, interfaces, and protocols that make up the OMA but does not in itself define them in detail. The OMA consists of five main components:
- Object Request Broker - this component, known as the Common Object Request Broker Architecture, or CORBA for short, lies at the heart of the architecture. Despite the enormous amount of attention that CORBA receives, the reader should not be fooled into thinking that this is the only component that falls under the standardization effort. Nonetheless, as mentioned above, it is the key communications component to the architecture.
- Object Services - refers to low-level services that need to be standardized too, such as transactional processing of method calls, the persistent storage of objects, and security mechanisms to name a few.
- Common Facilities - additional infrastructure services that are needed to open up other possibilities based on CORBA, such as a standardized administration service or a CORBA-based Compound Document Technology.
- Domain Interfaces - Domain Interface specifications represent vertical areas that provide functionality of direct interest to end-users in particular application domains.
- Application Objects - CORBA objects that are developed by the user and thus do not fall within the realm of the standardization effort.
The next player in the distributed object arena is Microsoft. Founded in 1975, Microsoft without question is the worldwide leader in software for personal computers. Over the last ten to fifteen years, they have mastered the art of the de facto standard at the PC level with their Windows-based operating systems and their office productivity suite, Microsoft Office. Today, Microsoft would love nothing more than to repeat this success by providing de facto standards to the enterprise computing world and to markets previously dominated by UNIX servers. They are attempting to do just that with their Windows NT network operating system, the Distributed Computing Object Model (DCOM), and a host of other products.
DCOM is an extension of Microsoft's very popular desktop component technology known as the Component Object Model (COM). COM has been a part of the Windows NT and Windows 95 operating systems for years. It is the mechanism in the OS that has made Object Linking and Embedding (OLE) and more recently Active X, possible. As an object-based programming model, COM was designed to support the development of software components at different times by different vendors using a variety of languages, tools, and platforms. DCOM extends the model specified by COM to work across the network and the internet. The extensions are in the areas of remote procedure calls, security, scalability and location transparency.
The choice of this "extension" strategy by Microsoft was an obvious one from their perspective. COM is in use on over 150 million systems worldwide, and has been licensed for use by Hewlett-Packard Co., Digital Equipment Corp., Siemens Nixdorf Information Systems Inc. and Silicon Graphics Inc. on UNIX and other systems (Microsoft Website). COM provides a rich set of existing services for applications, as well as the largest set of development tools available from a wide variety of vendors. As an extension of COM, the advantages of DCOM are quite evident. It can utilize existing WIN32 APIs and is a standard part of every Windows OS installation (Stal, 40).
Some have criticized Microsoft's platform-specific approach to distributed computing with DCOM. Indeed, Microsoft's de facto approach is in direct contrast to the collaborative efforts of the OMG consortium. Under the direction of Mr. Gates, Microsoft chooses a direction and then launches its employees full throttle in that same direction. In contrast, OMG welcomes the input of its 800+ members and non-members alike, transforming the input into standards specifications. The OMG approach is open and all-inclusive but can be slow and weighted down by member agendas and pocketbooks. The Microsoft approach is focused and fast, but is for the most part closed.
There is evidence however that Microsoft is not as closed and anti-competitive as many would make them out to be. Microsoft has formed a strategic alliance with German software giant, Software AG, with the goal of bringing DCOM to the Solaris-based operating system. Also, Microsoft is working with Internet standards bodies, such as the IETF, to offer DCOM to the Internet community as an open technology. The DCOM Protocol appears as an internet draft dated January 1998 on the IETF's website (see http://search.ietf.org/internet-drafts/draft-brown-dcom-v1-spec-03.txt). Are they just doing these things for show in response to criticisms? Or is Microsoft merely trying to create open, competitive frameworks to encourage the participation of third parties?
The final major player in the effort to standardize distributed objects is Sun Microsystems. Sun was founded in 1982 and since has grown into a global Fortune 500 leader in enterprise network computing with over $8 billion in revenues and operations in 150 countries. Its Java object-oriented programming language has gained incredible momentum in the last few years with widespread deployment. Seemingly overnight, Java has become the programming language of choice for application developers, both at the client and server ends, with its "Write Once, Run Anywhere" model. Among the characteristics that make Java so desirable are that it's "lightweight, rich, robust, secure, network-aware, and portable" (Orchard, 34). Like Microsoft, Sun too hopes that Java technology can become a de facto industry standard architecture for the Internet and corporate intranets.
Java Remote Method Invocation (RMI) is JavaSoft's language specific broker solution, allowing Java-to-Java communications across virtual machines. JavaBeans is the component model for Java, developed by a consortium of companies led by Sun. JavaBeans is also a term used to describe the reusable, object-oriented building blocks that make up a Java program. In the ideal world, any Java component that conforms to the JavaBeans component model can be reused in any other JavaBean-compliant application. Through a JavaBean property called introspection, any Bean that complies with the JavaBean model can be "read" by a visual tool that can analyze and report on the Bean's contents and on how it operates. Consequently, JavaBeans don't need to be registered the way that Active X components do. JavaBeans is significant to application development because it represents the first standard component model to be platform-independent (through the Java Virtual Machine). Finally, Enterprise JavaBeans is an extension to the JavaBeans model aimed at the middle-tier of the three-tier architecture. The extension adds mechanisms for multi-user security and resource management similar to the ActiveX model.
Up until last summer, these Java-based technologies were viewed as competitors to the OMG's CORBA/IIOP. However, this is no longer the case. In June of 1997, JavaSoft adopted CORBA as its distributed object model and announced plans to run the RMI APIs on top of CORBA/IIOP with help from the OMG. In effect, the JavaSoft and OMG camps have merged, creating an everyone versus Microsoft atmosphere ('everyone' being led by the so-called Gang of Four: Sun, Netscape, IBM, and Oracle).
The Present and Future of Distributed Objects
Microsoft, Sun, IBM, and Netscape all have bet a large part of their internet futures on distributed object models. According to the Gardner Group, by next year, ORBs will be the dominant mode of component communication for new applications. These things suggest the great importance of the standardization effort going on right now in this area. Presently, the distributed object environment can best be described as emerging. Some using less pleasant terms have labeled it a "mess". The Object Web, a term given to the notion of bringing distributed objects to the Web, is full of incompatible interfaces and untested standards (Orfali et al, 1). Heated debates (sometimes more personal than technology-related) cover everything from network component models (ActiveX and JavaBeans; COM, CORBA, IIOP, and RMI) to transaction systems (CICS, Tuxedo, and MTS).
On paper, all of the competing technologies claim to be platform-independent component standards. But so far, the commercial reality is proving to be much different. It is true that Java and CORBA are available on a variety of platforms, but interoperability issues are continuously being discovered and worked out. And although Microsoft is working with several vendors (Software AG, HP, and Digital for example) to port their windows-based COM to other operating systems, these ports are proving to be difficult as well (Pountain and Montgomery, 7).
In the short-term, there appears to be plenty of room for both the anti-Microsoft party and Microsoft itself. On the anti-Microsoft side, CORBA 3.0 is due out at the end of this year. It will introduce a new model dubbed CORBAbeans, thus further solidifying the marriage of Java and CORBA/IIOP. Based on the JavaBeans object model, CORBAbeans will enable rapid development of applications with more user-friendly tools and interfaces and it will feature improved COM-to-CORBA interoperability. According to the OMG, part of the goal is to create a market for cross-platform components that rivals the platform-specific ActiveX component market. From JavaSoft, the word is that future Java Development Kits (JDKs) due out later in the year will include a pure-Java CORBA ORB and support for Enterprise JavaBeans.
Meanwhile on the Microsoft side, there is evidence that traditionally UNIX and CORBA-based vendors are willing to integrate COM into their technology solutions. A number of recent announcements have helped to jumpstart COM's cross-platform status. Namely, back in January, Iona licensed COM from Microsoft with the intention of integrating it to provide interoperability with its Orbix CORBA implementation. Also, UNIX vendor Silicon Graphics announced it would be integrating COM support into its IRIX-based computers.
In the long-term, it is very difficult to determine who will come out ahead. This can be very depressing news to a corporation attempting to choose among the competing technologies. The good news is that, regardless of the choice of technologies, the benefits of adopting the Object Web and distributed component approaches are clear. And choosing one technology over the other may not be necessary, depending on the needs of your applications. You can often utilize so-called rival technologies in the same implementation. For example, IIOP can be used to communicate between ActiveX controls or JavaBeans (Pountain and Montgomery, 8).
Hopefully, this paper has provided both a background on distributed objects and why they are important, and a clear picture of this complicated, competitive, and fast-paced standardization arena. Beyond this paper, there is a ton of additional reading that can be done to further explore the details of the competing technologies and draw conclusions for yourself. There are also plenty of news groups available on the topic (with the caveat that they can deliver 20-100 mail messages to your inbox per day). Those who are interested will have to stay tuned for at least the next few years to see if either Microsoft or the Gang of Four can win outright. From an IT standards student's perspective, may the best solution, in terms of both technology and market satisfaction, win.
API - Application Program Interface
ATM - Automated Teller Machine
CICS - Customer Information Control System
COM - Component Object Model
CORBA - Common Object Request Broker
DCOM - Distributed Component Object Model
DNA - Distributed interNet Applications Architecture
IETF - Internet Engineering Task Force
IIOP - Internet Inter-ORB Protocol
MTS - Microsoft Transaction Server
OLE - Object Linking and Embedding
OMA - Object Management Architecture
OMG - Object Management Group
ORB - Object Request Broker
OS - Operating System
RFI - Request for Information
RFP - Request for Proposal
RMI - Remote Method Invocation
RPC - Remote Procedure Call
Alwang, G. How JavaBeans Work. PC Magazine. Vol. 17 No. 7, April 7, 1998. (http://www.zdnet.com/pcmag/features/java98/289767.html)
Gonsalves, A., Moeller, M. JavaBeans key to CORBA upgrade. PC Week Online. February 2, 1998. (http://www.zdnet.com/pcweek/news/0202/02corba.html)
JavaSoft's Website (http://www.javasoft.com).
Microsoft's Website (http://www.microsoft.com).
The Object Management Group's Website (http://www.omg.org).
Orchard, D. Java Component & Distributed Object Technologies. Object Magazine. January, 1998. pp 30-37.
Orfali, R., Harkley, D., Edwards, J. CORBA, Java, and the Object Web. BYTE Magazine. October 1997. (http://www.byte.com/art/9710/sec6/art3.htm).
Pountain, D., Montgomery, J. Components and the Web are a Match Made in Developer Heaven. BYTE Magazine. August 1997. (http://www.byte.com/art/9708/sec5/art1.htm).
Schulte, R. Architecture and Planning for Modern Application Styles. Gartner Group Strategic Analysis Report R-ARCH-104. April 28, 1997.
Seltzer, L. Looking Forward: Distributed Computing. PC Magazine. Vol. 16 No. 6, March 25, 1997. pp 198-200.
Stal, M. Worldwide CORBA: Distributed Objects and the Net. Object Magazine. March 1998.