Client/Server Fundamentals
February 8, 1999

Objects and Distributed Objects

2.4 Objects and Distributed Objects

In addition to client/server and Internet, we are in the midst of object orientation (OO), with names like OO programming, OO design, OO databases, OO user interfaces, and so on. Most new software being developed at present and in the future will use some level of OO (at least in the user interface displays). Let us discuss the core OO technologies (e.g., OO user interfaces, OO programming languages, OO databases), and introduce the distributed object concepts. We will discuss only those topics that are of relevance to object-oriented client/server Internet environments. For the uninitiated, a short tutorial in Section 2.12 ("Appendix 2A: Object-Oriented Concepts" at the end of this chapter), gives the basic information. Extensive discussion of OO concepts can be found in the books by Booch [1994], Rumbaugh [1994], Taylor [1994].

2.4.1 Core Object-Oriented Technologies

The basic object concepts are comprised of object, message, class, and inheritance. When used in building software systems, these concepts can be of great value in developing reusable and flexible systems. In particular, OO concepts are being used in OO user interfaces, OO programming languages, and OO databases.

Object Oriented User Interfaces. At present, almost all new applications provide user interfaces that are either GUI (graphical user interface) or OOUI (object oriented user interface). GUI provides graphic dialogs, menu bars, color, scroll boxes, and pull-down and pop-up windows. GUI dialogs use the object/action model where users can select objects and then choose the actions to be performed on the selected objects. Most GUI dialogs at present are serial in nature (i.e., perform one operation at a time). OOUIs are highly iconic, object oriented user interfaces to support multiple, variable tasks whose sequence cannot be predicted. Examples include multimedia-based training systems, executive and decision-support systems, and stockbroker workstations. OOUIs are supported by commercial products such as NextStep, OS/2 Workplace Shell, and Macintosh.

Object-Oriented Programming. A significant proportion of software at present is being developed in object-oriented or object-based programming languages. Object-based programming languages such as ADA and Modula support objects as a language feature but do not support the concept of inheritance. Object-oriented programming languages (OOPLs) support inheritance. Several object-oriented programming languages have been introduced over the years. The first object-oriented language, Smalltalk, was introduced in the 1960s. Since then, several OOPLs such as C++, Objective C, and Object Pascal have been introduced. A more recent example is the Java programming language. An early review of some of these and many other OOPLs can be found in the OOPL survey by Saunders [1989]. More recent reviews can be found in Meade [1995], and Pancake [1995]. For continued developments in OOPL, the Journal of Object Oriented Programming Languages should be consulted.

Object-Oriented Databases. Simply stated, object-oriented databases allow storage and retrieval of objects to/from persistent storage (i.e., disks). Object-oriented databases, also known as object databases, allow you to store and retrieve nontraditional data types such as bitmaps, icons, text, polygons, sets, arrays, and lists. The stored objects can be simple or complex, can be related to each other through complex relationships, and can inherit properties from other objects. Object-oriented database management systems (OODBMS), which can store, retrieve and manipulate objects, have been an area of active research and exploration since the mid-1980s. The initial work in OODBMSs was driven by the computer-aided design and computer-aided manufacturing (CAD/CAM) applications [Spooner 1986].

Relational databases are suitable for many applications and SQL use is widespread. However, it is not easy to represent complex information in terms of relational tables. For example, a car design, a computing network layout, and software design of an airline reservation system cannot be represented easily in terms of tables. For these cases, we need to represent complex interrelationships between data elements, retrieve several versions of design, represent the semantics (meaning) of relationships, and utilize the concepts of similarities to reduced redundancies. Additional information about object-oriented databases can be found in Davis [1995], Kim [1990], and Loomis [1995].

In addition to these, many new OO technologies are emerging, and market segments are evolving for reusable software that can be assembled to quickly build new applications (see the sidebars on "Object Frameworks" and "Component Software and Applets"). However, these technologies are introducing new terms and jargon. Due to ever-growing 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.

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 initializing 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 stand-alone application, it only works with other applications components.

Does everybody agree upon what a component is? Of course not (that would be a miracle!). However, most agree that (a) it is an independently delivered software and (b) it has an interface. A component may not have all the features of an object (i.e., inheritance and polymorphism) but it may be constructed from objects ("Components are molecules, objects are atoms," [Frye 1996]). Components are very much like objects; however, the emphasis is on recognition by users (many objects are oriented towards programming tasks).

Why are components important? The reason is simple–they can be used as plug-and-play to build complete applications. It is possible that components could finally realize the long-term dream of many pundits, that is, assemble software as you assemble cars instead of custom building each application. Many predictions are pointing to component-based software assemblies as being the norm in the next millennium [Vaughan-Nichols 1997], [Fingar 1996], and [Frye 1996].

At present, Microsoft appears to lead the component software by producing applets for Windows environments that draw, produce charts, perform calculations, etc. Depending on the size of the application, the components may be small or large. 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). This will change quickly as more components become available for Web applications (this is the basic philosophy of Microsoft’s ActiveX). Other vendors are naturally joining in.

Object Frameworks

Object frameworks, also known as "Frameworks," are essentially descendents 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. An object framework simply defines how given sets of classes are related and arranged for different application domains. Let us use an example to explain the object frameworks. Suppose that you want to build a car. You have the following choices:

l Custom build all parts (wheels, seats, engine parts, etc.) yourself and then assemble these parts into a car. This is the old fashioned way of building a system from the scratch.

l Buy as many pre-fabricated parts as possible and then extend-assemble them into a car. This is analogous to the class libraries for building applications.

l Buy a pre-fabricated frame which already has the basic components already assembled (e.g., the engine is already installed, and the places where you need to plug in new components are clearly marked). This is like object frameworks.

In essence, object frameworks contain class libraries that have been integrated for certain domains Additionally, frameworks are extensible and can talk to other frameworks. It is possible to view frameworks at the following levels.

Foundation classes provide fine grained data and control statements, I/O functions, GUI structures, memory management functions, and database access functions.

Middleware framework covers an extensive set of C/S middleware services such as transaction processing, database access, directory services, telephony, authentication and systems management.

Application frameworks, also known as desktop frameworks, provide programmer productivity tools for compound documents, multimedia, groupware, mail, 3D graphics, and decision support applications.

Frameworks provide a convenient mechanism for component software. Basically, components can be integrated into frameworks and new components can be added to frameworks to build applications [Wooding 1997], and [Pree 1996].

Microsoft’s Active Platform is an example of object frameworks. Web-based development environments from vendors such as Netscape are touting to be frameworks [Burr 1996]. Another example is the IBM object frameworks strategy that is expected 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, Easel, and others. Frameworks for domains such as manufacturing are also evolving [Appley 1996].

2.4.2 Distributed Objects for Enterprisewide Applications

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/applications across the network. Conceptually, enterprisewide applications are decomposed into objects that can reside around the 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. 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.

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

l A customer can be defined as a class from which other business classes that define different types of customers can inherit properties.

l An inventory can be defined as a class from which other properties of specific inventory items can be inherited.

l An entire legacy application can be viewed as an object (or a class) by using object wrappers that mediate between legacy systems and OO users (we will discuss object wrappers in later chapters).

Figure 2.9 shows a conceptual view of a distributed object model:

l Objects are data surrounded by code with properties such as inheritance, polymorphism, encapsulation, and the like. Objects can be clients, servers, or both.

l Object brokers allow objects to dynamically find each other in a distributed environment and interact with each other over a network. Object brokers are the backbone of distributed object-oriented systems.

l Object services allow the users to create, name, move, copy, store, delete, restore, and manage objects.

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 is natural to think 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]).

Figure 2.9 The Basic Distributed Objects Model

2.4.3 CORBA and ActiveX–Middleware for Distributed Objects

Support of distributed object applications requires special purpose middleware that allows remotely located objects to communicate with each other. Examples of middleware for distributed objects include Object Management Group’s (OMG’s) CORBA (Common Object Request Broker Architecture), and Microsoft’s ActiveX. Both of these middleware packages use the distributed object model based on the object request broker (ORB) that receives an object invocation and delivers the message to an appropriate remote object (see Figure 2.9).

CORBA was introduced in 1991 by OMG to specify the technology for interoperable distributed OO systems. CORBA specifications represent the ORB technology adopted by OMG and are published as OMG documents. The key concepts of CORBA are (see Figure 2.10):

l CORBA essentially specifies the middleware services that will be used by the application objects.

l Any object (application) can be a client, server or both. For purpose of description, CORBA uses the C/S model where clients issue requests to objects (service providers).

l Any interaction between objects is through requests. The information associated with a request is an operation to be performed, a target object, zero or more parameters, etc.

l CORBA supports static as well as dynamic binding. Static binding is used to identify objects at compile time while dynamic binding between objects uses run time identification of objects and parameters.

l An interface represents contracts between client and server applications. A typical interface definition shows the parameters being passed and a unique interface identifier. An Interface Definition Language (IDL) has been defined specifically for CORBA. Program stubs and skeletons are produced as part of the IDL compiling.

l CORBA objects do not know the underlying implementation details–an object adapter maps generic model to implementation and is the primary way that an object implementation accesses services provided by the ORB.

Figure 2.10 CORBA Conceptual View

ActiveX was introduced by Microsoft in March 1996 as its main strategy for distributed objects and Web. Microsoft is positioning ActiveX as a complete environment for components and distributed objects. Almost everything coming out of Microsoft at the time of this writing is based on ActiveX. Although ActiveX provides many capabilities, from a distributed objects point of view, the following features are significant (see Figure 2.11):

l All ActiveX components communicate with each other by using DCOM. So a Java applet (an ActiveX component) can call a remotely located Microsoft Word document (another ActiveX component) over DCOM. DCOM is the ORB in the ActiveX environment.

l The Web browser can behave as a container. For example, the Microsoft Internet Explorer can contain components such as Word documents, Java applets, C code, and Excel spreadsheets.

l Web technologies (browsers, HTML pages, Java applets) can be intermixed with desktop tools (spreadsheets, word processors) for distributed applications.

l Server facilities such as SQL servers and legacy access gateways can be invoked from ActiveX clients.

Figure 2.11 ActiveX Conceptual View

CORBA and ActiveX are reviewed in Umar [1997, Chapter 7]. Additional information can be found in Orfali [1996], Chappell [1996], Mowbray [1995], Linthicum [1997].