Most of the new applications being developed at present are based on the OO concepts. However, these objects are increasingly dispersed on multiple machines. Consequently, many new applications are being based on distributed-object concepts. These applications combine two very powerful concepts to deliver business value: object orientation and distributed systems. The users of these applications interact with objects that may be located locally or on remote machines. There are many interesting examples of distributed-object applications. A common example is the compound documents that serve as containers for objects such as text paragraphs, spreadsheets, graphs, and sound bites from different sites. Other examples exist in marketing, retail, entertainment, telecommunications, health, and many other areas.

The purpose of this chapter is to review the distributed-object concepts and examine the middleware that enables distributed-object applications. In particular, we will attempt to answer the following questions (this chapter assumes that the reader has a basic understanding of object-oriented concepts as discussed in the tutorial in Chapter 10):

A distributed application can be viewed as a collection of objects (user interfaces, databases, application modules, customers). Each object has its own attributes and has some methods which define the behavior of the object (e.g., an order can be viewed in terms of its data and the methods which create, delete, and update the order object). Interactions between the components of an application can be modeled through "messages" which invoke appropriate methods. In particular, classes and inheritance are extremely useful in modeling applications because these concepts lead to reuse and encapsulation–critical to managing the complexity of distributed systems. For example:

Before getting involved with details about objects in distributed systems, let us quickly review some of the key concepts. Figure 7.1 shows a conceptual view that will be expanded and refined later:

It should be kept in mind that modeling in terms of object-oriented (OO) concepts does not necessarily imply use of object-oriented programming languages such as C++ or object-oriented database managers. In fact, it is possible to view systems in terms of GUI objects and then implement them in whatever technology makes sense.

Most of the applications so far have used OO technologies at the client side to implement GUIs. However, there is no reason why this technology should not be equally valuable to servers also. In fact, the reuse and encapsulation features of OO technologies should be of value to manage the complexity of server implementations. It appears that the OO technologies will be increasingly used at the client as well as server sides of applications (see, for example, Shan [1995] and Rymer [1993]).

Owing to the interest in object-oriented systems, the elegance with which complex distributed systems can be modeled by using OO concepts, and the appeal of OO technologies in developing new applications ranging from inventory control to network management, many attempts have focused on standardized middleware to support object-oriented distributed systems [Rymer 1995, Rymer 1993, Harmon 1993, Wayner 1994]. The Common Object Request Broker Architecture (CORBA) from the Object Management Group is a prime example of such a standard.

Figure 7.1 The Basic Distributed-Objects Model

A very wide range of OO products are commercially available from a diverse array of suppliers. These products include user-interface development aids such as Galaxy; compilers for OO programming languages such as C++, Smalltalk, Simula, and Eiffel; OODBMSs such as ObjectStore and Gemstone; and complete OO development environments such as Expersoft to support code reuse. In addition, class libraries such as Tools.h++ are becoming widely available. Instead of reviewing these products, let us briefly review the following three emerging areas:

Object Frameworks. Object frameworks are essentially descendants of object-oriented class libraries. Class libraries are collections of predefined object classes that define commonly used presentation, business processing logic, and data-management structures and methods. A framework simply defines how given sets of classes are related and arranged for different applications. It is possible to think of frameworks at three levels: foundation classes, middleware frameworks, and application frameworks (or high-level frameworks). The foundation classes provide fine-grained data and control statements, I/O functions, GUI structures, memory-management functions, and database-access functions. The middleware framework covers an extensive set of C/S middleware services such as transaction processing, database access, directory services, telephony, authentication, and systems management. The application frameworks, also known as desktop frameworks, provide programmer productivity tools for compound documents, multimedia, groupware, mail, 3D graphics, and decision-support applications. An example of commercial object frameworks is the IBM object-frameworks strategy that is beginning to materialize as products. The objective of this strategy is to create "seas of objects" with object frameworks as the glue to tie these objects into applications. Examples of other players in this market are ParcPlace Systems, Rogue Wave, ILOG, Next, Sun Microsystems, and Easel.

Business Objects. The basic idea of business objects is that the users can construct objects that represent the real-world concepts of the business world. Examples of business objects are customer, order, products, and regional office. If software could be structured around such objects and other business concepts, then organizations would be able to build software that simulated current business strategy. Moreover, businesses could reuse these objects to build new applications by using the OO paradigm. Business objects started appearing in the marketplace around 1994 when OLE 2.0, OpenDoc, and CORBA-based products started emerging. Since then, OO tools designed to support creation of business objects have appeared from vendors such as Easel and applications that employ business objects have appeared from vendors such as IMRS. The Object Management Group (OMG) has founded the Business Object Management Special Interest Group (BOMSIG) to help the industry understand and utilize this technology effectively. System integrators such as Anderson Consulting are also committing to deliver software environments that can be used to build custom applications based on business objects. Additional information about business objects can be found in Sims [1995], and Rymer [1995].

Component Software and "Applets." Components are high-level "plug and play" software modules that perform a limited set of tasks within an application. Components are essentially small applications, also known as applets, that are recognizable by the users (i.e., they do not perform internal programming tasks such as initialize internal memory locations). For example, Microsoft Draw is an applet within Microsoft applications. This particular component is high-level enough to perform end-user type functions (it draws boxes, arrows, circles, etc.). However, it is not a standalone application; it only works with other applications components. At present, Microsoft appears to lead in component software by producing applets for Windows environments that draw, produce charts, perform calculations, etc. Java applets are another popular example. Depending on the size of the application, the components may be small or large. Components are very much like objects; however, the emphasis is on recognition by users (many objects are oriented toward programming tasks). Thus component software can be used as plug and play to build complete applications. Many desktop tools are currently becoming available as components. Examples of typical desktop components are spell-checkers, SQL query builders, and print managers (conceptually, each icon on your toolbar can be a separate component).

These and other emerging technologies and market segments are leading toward reusable software that can be assembled to quickly build new applications. However, these technologies are introducing new terms and jargon. Owing to an ever growing list of object-oriented "things," many groups are trying to figure out what to do. An example is the Object Management Group (OMG) that has been formed as a nonprofit consortium of more than 500 software and systems manufacturers and technology information providers. OMG is specifying a set of standard terms and interfaces for interoperable software by using the object-oriented concepts.

The trend at present is to extend the OO concepts to enterprisewide distributed applications. Simply stated, distributed objects are objects that can be dispersed across the network and can be accessed by users across the network. Conceptually, we are talking about decomposing enterprisewide applications into objects that can be dispersed around different machines on a network. An object on one machine can send messages to objects on other machines, thus viewing the entire network as a collection of objects. This concept naturally extends the notions of object frameworks, business objects, and component software to distributed systems. When, and if, fully realized, distributed objects present a very powerful technology that has the potential of addressing many problems facing the IT community today (i.e., reuse, portability, and interoperability). This is because applications can be constructed by using reusable components that encapsulate many internal details and can interoperate across multiple networks and platforms.

Support of distributed-object-based applications requires special-purpose middleware that will allow remotely located objects to communicate with each other. A common mechanism used by such middleware is an object-request broker (ORB) that receives an object invocation and delivers the message to an appropriate object. Examples of middleware for distributed objects include OMG’s CORBA (Common Object Request Broker Architecture), Microsoft’s OLE (Object Linking and Embedding), and Component Integration Laboratories’ OpenDoc.

Interfaces and interface definition languages (IDLs) are at the core of distributed-object applications. Simply stated, an interface specifies the API that the clients can use to invoke operations on objects. In particular, an interface describes:

For distributed-object applications, interface definitions are used to advertise the set of operations that an object can provide to prospective clients. Thus the object’s data is accessible only through the interface. Consequently, any server that is encapsulated by its interface can be viewed as an object [Mowbray 1995, Nicol 1993]. Figure 7.2 shows an interface of a simple inventory object that supports two operations: query inventory and update price (a definition of this interface is given in Table 7.1). These operations can be invoked by client programs.

Figure 7.2 Example of an Interface

One or more interfaces may be defined for an object. For example, given an object such as inventory, you may need to define three different interfaces: one for the manager of inventory (i.e., to create, monitor, and replenish the inventory), one for the order-processing system (i.e., to retrieve and update the inventory), and one for the authorized customers (i.e., to browse through the available products). It is a good practice to design interfaces for different classes of users and to group-related operations together. An interface definition includes some or all of the following:

The interfaces are defined by using an interface definition language (IDL). Different middleware products provide IDL compilers that parse the IDL and produce header files and code segments that are used by the client and server programs (we will discuss this in more detail later). For example, OSF DCE, CORBA, and OLE all provide IDL compilers. In addition, middleware products support utilities and commands to store and retrieve IDLs from interface repositories. Client application developers can browse through these interface repositories to learn about the available server objects and determine the type of operations that can be invoked on an object.

IDLs are basically declarative languages–they do not specify any executable code. IDL declarations (e.g., syntax, character types allowed, argument coding, etc.) must conform to the vendor-provided IDL compilers. After you create the interface definition using IDL, you compile the IDL file to create header files and "stubs" that are used in building clients and servers. Table 7.1 shows the IDL of a simple inventory system that supports query-inventory and update-price operations. The syntax used in this example is abstract. We have seen the DCE IDL in a previous chapter and will see actual IDL specifications for CORBA.

Interfaces significantly impact the design of distributed-object applications. First, the server object is required to implement at least the operations specified in the IDL, and the client is required to accept at least the set of results generated by the IDL operations. This implies that the server will never respond with a "method/procedure not supported" message to a prospective client. Second, the clients may not use some of the operations provided by the interface. This implies that the server interfaces can be extended to include more operations without requiring any change to the client. Finally, and most importantly, the "size" of the interface needs to be carefully examined. For example, it is not a good idea to specify an interface that supports 100 operations. In such a case, if one operation needs to be changed, then a new IDL will have to be compiled and all client programs will have to be recompiled (this could be quite irritating). It is best to design a separate interface for each group of users (e.g., one interface for end users, one for the system administrators, etc.).

Interfaces and IDL provide the basic glue for distributed-object computing. IDL is used not only to define new services provided by objects, but also to "wrap" existing and legacy systems so that they behave externally as objects. For example, a legacy application written in COBOL could behave as a server object as long as it has an IDL and it provides the operations defined by the IDL. Thus the "IDL-ized" programs run on top of an ORB without revealing their internal details (see Figure 7.3).