Frameworks for Component-Based Client/Server Computinglee/00cis640/papers/lewandowski.pdf · Frameworks for Component-Based Client/Server Computing SCOTT M. LEWANDOWSKI ... in which

Frameworks for Component-Based Client/Server ComputingSCOTT M. LEWANDOWSKI

Department of Computer Science, Brown University, Providence, RI 02912-1910 ^[email protected]&

1. INTRODUCTION

This article introduces the basics of cli-ent/server computing and componenttechnologies and then proposes twoframeworks for client/server computingusing distributed objects. I discuss top-ics affecting client/server frameworks,with a focus on the delegation of respon-sibilities between clients and serversand the stratification of client/serversystems into levels. The componenttechnologies I discuss are CORBA, theObject Management Group’s proposalfor a distributed object framework, andDCOM, Microsoft’s system for creatingand using objects on remote machineswhile maintaining the common para-digm for interaction among libraries,applications, and system software pro-vided by COM [Chappell 1996]. Ac-tiveXs, components built from COM-based technologies, are treated asimportant examples of DCOM parts inclient/server systems. It should be notedthat JavaBeans is not discussed, since itis a language-specific technology andnot suitable for use in an environmentwhen the participating components arenot necessarily all written in Java. TheJava programming language is dis-cussed in terms of its contributions toan effective framework for client/servercomputing using the distributed objectservices of CORBA. Java applications,which are suitable for downloading to alocal machine from the World WideWeb, are discussed as Java componentunits providing total integration frame-

works for client/server computing whileusing distributed objects.

2. WHAT IS CLIENT/SERVERCOMPUTING?

Client/server computing systems arecomprised of two logical parts: a serverthat provides services and a client thatrequests services of the server. To-gether, the two form a complete comput-ing system with a distinct division ofresponsibility. More technically, client/server computing relates two or morethreads of execution using a consumer/producer relationship. Clients serve asthe consumers in a client/server system.That is, they make requests to serversfor services or information and then usethe response to carry out their own pur-pose. The server plays the role of theproducer, filling data or service requestsmade by clients.

Client/server computing attempts toleverage the capabilities of the net-works used by typical corporations thatare composed of many relatively power-ful workstations and a limited numberof dedicated servers. Client/server com-puting has gained popularity in the re-cent years due to the proliferation oflow-cost hardware and the increasinglyapparent truth of the theory that amodel relying on monolithic applica-tions fails when the number of usersaccessing a system grows too high orwhen too many features are integratedinto a single system.

A good example of a client/server sys-

Permission to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1998 ACM 0360-0300/98/0300–0003 $5.00

ACM Computing Surveys, Vol. 30, No. 1, March 1998

tem is a simple automated teller ma-chine (ATM) network. Users typicallyuse ATMs as clients to interface with asmall sub-server, which collaborateswith a larger server that manages all ofthe smaller servers. In this model, thesub-servers are servers to the ATMsand clients to the master server. ATMsprovide the user interface and can becustomized as required (e.g. for multi-lingual support), while the intermediateservers provide the application logic,such as checking account balances andtransferring money between accounts.The sub-servers allow the system to bescaled since adding servers allows anincreased number of ATMs to be sup-ported. However, the application logic isprovided only with the help of the cen-tralized server. The results of the ser-vices are communicated to the userthrough the ATMs. The centralizedserver provides additional applicationlogic, such as ensuring that concurrenttransactions are handled correctly. Italso serves as a central brokerage for allaccount information so that users canaccess their accounts from any ATMworldwide.

2.1 Clients

Many clients have a modern graphicaluser interface (GUI) that presents eachresource accessible by the user as anindependent object; the GUI is usuallyprovided with the help of the OS so thatconsistency across multiple applications

is maintained. A typical example of aGUI is the common desktop metaphorin which each storage device, file, andprinter is depicted as an independententity. Clients can also offer services toother clients. Normal models of client/server computing place no limit on thenumber of servers a client can accesssimultaneously.

2.2 Servers

“Traditional” servers are entities thatpassively await requests from clientsand then act on them, but recent re-search in this area encompasses sys-tems fulfilling the theoretical organiza-tion of client/server systems in whichservers can actively search out changesin the state of clients and take appropri-ate action. Servers typically fill one spe-cific need and encapsulate the providedservices so that the state of the server isprotected and the means by which theservice is provided are hidden from theclient. In order to accommodate work-station clients as first-rate networkmembers, servers must handle peer-to-peer protocols that are used for “filesharing” on PCs, handle PC messages,and service PC resources using nativeformats. An important consideration indetermining the granularity of servicesoffered by a server is the possibility ofhaving servers act as clients to otherservers. Using this model, a server canexecute a task by dividing it into sub-

Figure 1. A traditional client/server system. Clients request services of the server independently butuse the same interface.

4 • Scott M. Lewandowski


tasks and then having other serverscomplete the subtasks.

2.3 Middleware

The distributed software required to fa-cilitate client/server interaction is re-ferred to as middleware. Transparentaccess to non-local services and re-sources distributed across a network isusually provided through middleware,which serves as a framework for com-munication between the client andserver portions of a system. Middlewarecan be thought of as the networkingbetween the components of a client/server system; it is what allows thevarious components to communicate ina structured manner. Middleware is de-fined to include the APIs used by clientsto request a service from a server, thephysical transmission of the request tothe network (or the communication ofthe service request to a local server),and the resulting transmission of datafor the client back to the network.Middleware is run on both the clientand server ends of a transaction.

Middleware is where most of the com-mercial competition and development inclient/server computing has occurred.Examples of the proliferation of compet-ing domain-specific standards includedatabase middleware such as ODBC,SQL, and Oracle Glue; groupwaremiddleware such as Microsoft Exchangeand Lotus Notes; Internet middlewaresuch as HTTP and Secure Socket Layer(SSL); and object middleware such asCORBA and DCOM. “Generic” or “fun-damental” middleware forms the basisof client/server systems; the domain-specific middleware serves to harnessthe capabilities of the fundamentalmiddleware for a more specialized pur-pose. Network authentication services,queues (such as those for peripheralsor tasks), network procedure calls, dis-tributed file systems, and network timeservices are all considered part of thefundamental middleware. The most com-mon network communication protocolused by middleware is TCP/IP, although

IPX is also popular for some applica-tions.1 Fundamental middleware is be-coming a standard part of modern op-erating systems such as WindowsNT,reducing the importance of systemssuch as Novell’s NetWare; this shouldhelp to standardize the availability ofmiddleware.

2.4 Fat Servers vs. Fat Clients

Although clients and servers both playimportant roles in a successful client/server system, most systems are flexiblewith regard to the distribution of au-thority, responsibility, and intelligence.Information systems specialists dub apart of a system with a disproportionateamount of functionality “fat”; a “thin”portion of a system is a part with lessresponsibility delegated to it [Orfali etal. 1996a]. The server portion of a cli-ent/server system almost always holdsthe data, and the client is nearly alwaysresponsible for the user interface; theshifting of application logic constitutesthe distinction between fat clients andfat servers. Fat server systems, such asgroupware systems and Web servers,delegate more responsibility for the ap-plication logic to the server, whereas fatclient systems, such as most databasesystems, place more responsibility onthe client. Distributed object models ofclient/server computing are unique inthat either the client or the server canbe fat while still maintaining approxi-mately the same degree of flexibilityand power. However, shifting intelli-gence from the client to the server orvice versa shifts the capabilities andstrengths of the system. For example, ifa fat server is being used, it usually iseasy to update application logic since anew client does not need to be distrib-uted. However, if fat clients are being

1 Most domain-specific middleware is designed foruse with TCP/IP, and TCP/IP is supported bynearly all operating systems. Since Windows95and the MacOS support TCP/IP, almost all desk-top computer users have access to TCP/IP ser-vices.

Component-Based Client/Server Computing • 5


used, the server need not be touchedand system stability is not jeopardized.

Although systems relying on fat serv-ers have comprised the majority of cli-ent/server systems in the past, manyprogrammers now favor fat-client sys-tems because they are generally easierto program. Fat clients let users createapplications and modify complex front-ends to systems easily, but this comesat the price of reduced data encapsula-tion; as more responsibility is placed ona client, the client requires a more inti-mate knowledge regarding the organiza-tion of data on the serving end. How-ever, the continued development of fat-server systems has been significantlyinfluenced by the industry trend to-wards greater object orientation, whichfavors a high degree of data encapsula-tion. By encapsulating the data better,more abstract services can be providedby the server, and raw data is hiddenfrom the client. Instead of returningunprocessed data, meaningful responsesto service requests are communicatedback to the client by the server.

The use of fat servers has also in-creased because of their recently ex-ploited efficiencies. Generally, fat serv-ers are easier to manage and deploysince the data and code exist in a cen-tralized location. Instead of coordinat-ing it across a network, debugging is alldone from one machine; unfortunately,as mobile servers and processes becomethe norm, this benefit will become lessimportant. Fat servers reduce the prob-lem of limited bandwidth by carryingout more of the work where the dataresides, reducing the need for costly

data transfers over the network. Mis-sion-critical applications requiring thehighest degree of fault tolerance andstability use fat servers for ease ofmaintenance.

The fat server model is often used toensure greater compatibility betweenclients and servers: the more work theserver does, the less dependent it is onthe client. For example, a Web pagedesigned under the fat server modelwould assume that no plugins, ActiveX,or Java capabilities are available (be-cause the user is using a thin client, abasic Web browser), and the serverwould be restricted to the HTML 2.0standard. Using this thin-client modelensures that all users see an “accept-able” page in a predictable manner, al-though little flexibility for page designor functionality is possible without theuse of the advanced technologies. If amore robust user experience is needed(which, in this example, would be de-rived from using plugins and the like),the fat client model can be used at theexpense of universal compatibility.

2.5 N-Tiered Systems

The canonical client/server model as-sumes exactly two discrete participantsin the system. This is called a “two-tiersystem;” the application logic must be inthe client or the server, or shared be-tween the two. It is also possible to havethe application logic reside separatelyfrom the user interface and the data,turning the system into a “three-tiersystem.” In an idealized three-tier sys-tem, all application logic resides in a

Figure 2. Since the distribution of the user interface and data is fixed, the placement of the applicationlogic is what distinguishes fat-client from fat-server systems.



layer separate from the user interfaceand data. This rarely happens in actualsystems; usually, the bulk of the appli-cation logic is in the middle tier, butselect portions of it are the responsibil-ity of the client and/or the server.

The three-tier model is more ad-vanced and flexible than the traditionaltwo-tier model because the separation ofthe application logic from the client andserver gives application logic processesa new level of autonomy. The processesbecome more robust since they can oper-ate independently of the clients andservers. Furthermore, decoupling theapplication logic from the data allowsdata from multiple sources to be used ina single transaction without a break-down in the client/server model. Thisadvancement in client/server architec-ture is largely responsible for the notionof distributed data.

Standard Web applications are themost common examples of three-tiersystems. The first tier is the user inter-face, provided via interpretation ofHTML by a browser. The embeddedcomponents displayed by the browserreside in the middle tier; these could beJava applets, ActiveXs, or some otherkind of entity that provide the applica-tion logic pertinent to the system. Thefinal tier is the data served from a Webserver. Quite often this is a database-style system, but it can be a data-ware-housing or groupware system.

Many advanced applications can ben-efit from the use of more than threetiers. For example, when multiple datasources are integrated (as in a datawarehousing application), four tiers arepossible: the individual data reposito-ries, a server that unifies the view ofthis data, an application server thatperforms queries based on the unifiedview of the data, and the front end. Thedevelopment of efficient and reliablesystems with more than three tiers isstill an imprecise science, but researchin distributed computing continues toincrease the availability and usefulnessof such systems.

2.6 Functions and Benefits ofClient/Server Systems

Although client/server systems are gen-erally characterized by their compo-nents, they must serve essential func-tions in order to meet the demands ofnetwork computing. To prevent inflexi-ble local system organization, a client/server system must keep parts of theapplication loosely coupled; of course,communication via message passingmust continue in order to support thegranularity of communication (most of-ten, method invocation) required be-tween client and server. Access toshared resources must be regulated tohandle cases in which client and serverattempt to access the same resource(this occurs most often when client andserver are running on the same ma-chine) or in which multiple clients at-tempt to access the same resource viathe server. In addition, a client/serversystem must provide a standardizedsystem through which network servicescan be utilized to provide location–transparent access to all services.

As client/server systems have grownmore robust, the computing communityhas acknowledged their many distinctadvantages. Perhaps the most impor-tant advantage is the natural mappingof applications into a client/serverframework. A typical example of this isan electronic phonebook system. Sincethe data is relatively static (and is uni-form for all users of the system) and thedata repository needs to be able to re-spond to queries, it makes sense to con-struct this portion of the application asa server. A thin client is a logical matchsince it is difficult to update every us-er’s database of phone numbers, the op-timal search algorithm can change atany time, and the space required for theamount of data manipulated is prohibi-tive for many users’ workstations.

As a result of the availability of com-patible middleware for multiple plat-forms and recent advances in binaryinteroperability, client/server systemscan usually relate a client on one plat-



form to a server on another. Technolo-gies such as Java and object requestbrokers (ORBs) promise to provideseamless integration among all plat-forms within a few years. If portions ofa client/server system encapsulate asingle function and follow a rigid inter-face, those parts of a client/server sys-tem providing the services can be inter-changed without upsetting otherportions of the system. This allows usersto customize their environments formaximum efficiency and system admin-istrators to upgrade transparently tomore powerful, capable, or less expen-sive servers without notifying the users(clients). Application development issimplified since a client and server eachfill a specific need, and each properlydesigned server supports an interfacedirectly related to the realization of onecommon goal.

Client/server models leverage the ad-vantages of commodity-like hardwareprices since resource-intensive applica-tions can be designed to run on multiplelow-cost systems. Systems can growsince client/server systems scale bothhorizontally and vertically, meaningthat clients can be added with littleperformance penalty and that extra per-formance can be extracted from a client/server system by adding faster serverhardware.

Despite maintainability issues arisingfrom the distribution of data and codethroughout a network and the difficul-ties vendors have “keeping up” withcompeting standards, the client/servermodel is extremely well suited for manyapplications.

3. DISTRIBUTED OBJECTS ANDCOMPONENTS

As computing systems evolved, new par-adigms of constructing software applica-tions were developed and the paradigmof algorithmic computation was re-placed by the use of interacting objects.

3.1 From Objects to Distributed Objects

Classical objects can be viewed as self-contained entities that encapsulatedata, and a set of operations that act onthat data. The operations supported byan object (often called “methods”) mayrely on the internal state of the object.Objects provide a clean way of separat-ing related data and functionality fromother parts of a system in order to easesystem construction and maintenance.

Whereas regular objects “reside” in asingle program and do not even exist asseparate entities once the program iscompiled, distributed objects are ex-tended objects that can reside anywhereon a network and continue to exist asphysical standalone entities while re-maining accessible remotely by otherobjects. Robust distributed object sys-tems allow objects written in differentlanguages and compiled by differentcompilers to communicate seamlesslyvia standardized messaging protocolsembodied by middleware. Such objectframeworks allow higher levels of trans-parency of interoperability between dis-tributed objects.

3.2 Benefits of Distributed Objects

Distributed objects promise to revolution-ize the construction of scaleable client/server systems by providing modularizedsoftware that features interchangeableparts. Advanced architectures will offerthe end user the ability to add compo-nents, allowing simple customization ofapplications.

Objects designed for self-managementare the types of components most easilyutilized since they impose little burdenon the application programmer. Self-managing distributed objects take re-sponsibility for their own resources,work across networks, and interact withother objects. These capabilities are fre-quently given to objects through a dis-tributed object framework that providesmiddleware to regulate the necessaryinter-object communications and pro-vides a resource pool for each object



that is deleted when that object ceasesto exist. An example of such self-manag-ing objects is ActiveXs; the DCOMmiddleware ensures interoperation be-tween remote objects and handles re-source allocation.

Self-managing objects are used easilyby other objects since no managementburdens are imposed on the client ob-ject: it receives object services “at nocost.” Objects crafted to these specifica-tions rely on a solid event model thatallows objects to broadcast specific mes-sages and generate certain events.These events, which can be likened toan alarm signaling a human to takesome action, are “listened for” by otherobjects, which then take action based onthem. Each listening object responds toa given event in its own manner. Byusing object-oriented techniques such aspolymorphism, closely related objectsreact differently to the same event.These capabilities simplify the program-ming of complex client/server systemsand also help provide an accurate repre-sentation of the real-world system mod-eled.

Objects can generate events to notifyother objects that an action should takeplace. In this sense, events can beviewed as synchronization objects thatallow one thread of execution to notifyanother thread that something has hap-pened. Using this model, an event cannotify a component that it should take acertain action. An object that can listen

for events provides a more robustframework for interaction between ob-jects than a model that forces objects towait for the next instruction. For exam-ple, a word processor might generate a“finished printing” event when it hasspooled a document to a printer. Ifsomeone wants to add a display dialogalerting the user that the printing wasdone, it is necessary to write an objectlistening for the “finished printing”event; the word processor would notknow of the existence of the alert objectwithout it. Under a traditional model,the alert object needs to be told explic-itly to show the dialog; this requiresmodifications to the word processorsource code and subsequent recompila-tion, which is not always feasible.

Because of the strict encapsulationthat objects provide, distributed objectsare a fundamentally sound unit fromwhich to build client/server applicationswhen separation of data is important.Cooperating objects form the logic por-tion of most substantial client/serversystems because of the rich interactionservices they offer [Wegner 1997a;1997b]. The flexibility of granularity of-fered by components should not be over-looked. Objects can be as small as re-quired to provide the correct degree of“mixing” of services, or as large andcomplex as required to encapsulate com-pletely the logic of a particular systemsegment without unwarranted relianceon other objects.

Figure 3. A sample event management system. Depicted is CORBA’s Event Service, which isimportant because it extends CORBA’s otherwise synchronous communication model.



Since distributed objects allow appli-cations to be split up into lightweightpieces that can be executed on separatemachines, less powerful machines canrun demanding applications. Advancedapplications for which distributed ob-jects are well suited include roamingagents (autonomous objects that movelogically or physically within a network,performing various tasks at specifiedlocations) and objects that adjust dy-namically to their execution environ-ment to provide optimal performance inany given situation.

3.3 Components

Components are the smallest self-man-aging, independent, and useful parts ofa system that works in multiple envi-ronments. Such parts may not even beobjects; ActiveX controls (Microsoft’s no-tion of a standalone software componentthat performs a common task in a stan-dard way) provide one such example.Components promise rapid applicationdevelopment and a high degree of cus-tomizability for end users, leading tofine-tuned applications that are rela-tively inexpensive to develop and easyto learn.

Components are most often distrib-uted objects incorporating advancedself-management features. Such compo-nents rely on robust distributed–objectmodels so as to maintain transparencyof location and implementation. Compo-nents may contain multiple distributedor local objects, and they are often usedto centralize and secure an operation.For example, a function provided on aWeb page through JavaScript may bemoved to a component to protect thelogic of the application or to allow theoperation to execute on a more powerfulserver.

The interface of a component shouldbe the primary concern of its developer.Since components are designed for usein a variety of systems and need toprovide reliable services regardless ofcontext, developers attempting to use acomponent must be able to identify

clearly the function of a component andthe means of invoking this behavior.

4. A NEW MODEL FOR CLIENT/SERVERCOMPUTING

The use of distributed objects in client/server systems provides numerous ben-efits to end users and system develop-ers. If distributed objects are used, it isessential to choose the most appropriatedistributed object model and program-ming language in order to leverage theadvantages of the client/server para-digm.

4.1 Client/Server Using Distributed Objects

Due to market forces, only CORBA andDCOM provide viable long-term solu-tions to the challenge of a standardizedframework for object-based client/serversystems, since other technologies do notsupport a large enough feature set orhave as great an installed base andmomentum as these two systems.

4.1.1 Client/Server with CORBA.The computer industry has rallied tocreate an open standard for distributedobject computing, which is known as theCommon Object Request Broker Archi-tecture (CORBA).2 The most ambitiousmiddleware undertaking ever, CORBAmanages every detail of component in-teroperability, ensuring the possibilityof interaction-based systems that incor-porate components from multiplesources. Because an object’s servicespecification is completely separatedfrom its implementation, CORBA isable to provide a self-specifying systemthat allows the discovery of other ob-jects on the network; this capability

2 Traditionally, an open standard is a standarddesigned and supported by many companies thatprovides for interoperation between specific ven-dor implementations of similar systems; an openstandard allows continued innovation and devel-opment of the system by all companies working onit. The key benefits are: ready availability of infor-mation about the standard and assurance that noone company will gain a significant competitiveedge by having the “best” technology.



opens up new possibilities for interac-tive systems.

CORBA objects can exist anywhere ona network, and their location is com-pletely transparent. Details such as thelanguage in which an object is writtenor the operating system on which itcurrently runs are also hidden to cli-ents. The implementation of an object isof no concern to an invoking object; theinterface is the only consideration a cli-ent must make when selecting a servingobject.

CORBA provides fundamental systemand application services to the objectsthat rely on it for management. Theinclusion of these services at themiddleware level eliminates the needfor most “mixin classes” (small classesproviding generic functionality, such asgarbage collection or persistence, to allobjects inheriting from them); theseclasses tend to distort the object modeland unnecessarily complicate the inher-itance hierarchy of systems.3

The most important part of a CORBAsystem is the Object Request Broker(ORB). The ORB defines the objectmodel and provides bidirectional loca-tion-transparent object access. The ORBis what shields clients from the neces-

sity of dealing with the complexities ofremote object communication; the ORBhandles all of the difficulties in coordi-nating the task. The CORBA 2.0 specifi-cation mandates intervendor ORB com-patibility, which is accomplished via therequired Internet Inter-ORB Protocol(IIOP). IIOP provides a common com-munication backbone between differentORBs by adding several CORBA-spe-cific messages to the TCP/IP schemaalready widely used today. The ORBprovides most of the middleware-likeservices that a robust distributed objectsystem should provide. Many CORBAfeatures are drawn from proven modelssuch as Remote Procedure Calls (RPC)and Message-Oriented Middleware(MOM).

CORBA uses the ORB to establish aclient/server relationship between com-ponents. The ORB intercepts methodinvocations from client objects androutes them to an appropriate server.The serving component can be a specificobject or a general server that deliversthe services required to meet the de-mands of a generic client request. Byusing an ORB with such capabilities,CORBA shields the programmer fromimplementation details (e.g. the lan-guage used to write the cooperatingcomponent) as well as run-time vari-ables (e.g. the details of which machinehosts a given component). The ORBdoes not bind a given component to aclient or a server role: the same compo-nent acts as a client to other objects yet

3 In fact, the CORBA model does use mixins toprovide these services, but they do not interferewith the “traditional” object interface since theyare mixed in at run time. Mixins could also beincluded at build time, but this limits the flexibil-ity of the model.

Figure 4. The CORBA architecture. The major ORB components used by the client and the implemen-tation of the object are shown.



still delivers requested services, makingit also a server.

At the heart of CORBA’s strong in-teroperability is the language-neutralInterface Definition Language (IDL).The IDL, used to specify the servicesthat an object can provide, was designedto be fully independent of the imple-mentation language, tools, operatingsystem, and other factors that normallyaffect interoperability. Important issuessuch as error handling are accounted forby this completely declarative language.Programmers write interactive se-quences of code using native languageconstructs and rely on the IDL only toexpress object interfaces and relatedtraits, such as its inheritance tree, theevents that the object can trigger, andthe exceptions the objects raise (for er-ror-handling purposes). When the inter-face is specified, the programmer speci-fies parameter and return types toensure the appropriate invocation of theobject’s methods. To make the IDL easyto learn, it is a superset of C11; theIDL even includes support for prepro-cessor directives.

Client IDL stubs communicate thestatic interfaces that allow a client to bewritten as though it simply invoked lo-cal methods; in reality, the ORB routes

the method invocations to the appropri-ate server objects. This flexibility comesat the expense of equipping each clientcomponent with an IDL stub for eachserver used. In addition to staticmethod invocation, CORBA supportsdynamic method invocation, which ishandled through the Dynamic Invoca-tion Interface (DII). DII allows a compo-nent to learn about the methods of othercomponents at run time. It serves as ageneric interface that does not requirestubs; instead, it supports the dynamicconstruction of method invocations asneeded by the client at run time. Stan-dardized methods support the transferof data in a metadata format; however,the full utility of DII is yet to be ex-ploited due to the complexities inherentin writing a component that uses ser-vices not yet known to exist.

The server side of a client/servertransaction need not know whether themethod invocation it handles is static ordynamic. Serving objects have ServerIDL Stubs, similar to the Client IDLStubs, that denote the static interface ofthe serving component. To accommo-date components without IDL-basedstubs, CORBA provides a DynamicSkeleton Interface (DSI) that binds in-coming method calls for such objects at

Figure 5. The structure of a CORBA IDL file.



run time. Server demands are met viaan Object Adapter, which provides thecore run-time functionality required byservers. It supports the registration ofcomponents, and thus returns objectreferences to client components. TheImplementation Repository gives servercomponents a repository for run-timeinformation about a variety of a server’sservices such as the supported inter-faces, audit trails, security details, andother administrative or “housekeeping”information.

Related to these two interfaces is theInterface Repository API, which allowscomponents to obtain and modify theinterfaces of registered components towhich it has access. The Interface Re-pository contains all of the IDL defini-tions, which describe the attributes, op-erations, user-specified types, andexceptions supported by server objects.Using the Interface Repository API,components can update their publishedinterfaces, making CORBA a self-de-scribing system. By supporting theseflexible interface services, CORBA pro-vides both the safety and speed of staticmethod invocation as well as the flexi-bility afforded by dynamic method invo-cation.

CORBA specifies two means by whichan object can locate another object in asystem. The first is the Naming Service.This service is analogous to the whitepages in a phone book: an object looksup another object by the name under

which the object registered itself withthe ORB on initialization. This methodof finding an object relies on uniquesignatures: a client must know the ex-act name a server gave when it regis-tered for use. The second service is theTrader Service, which is like the yellowpages: objects can ask the Trader Ser-vice what objects with certain servicecharacteristics have registered. Thetrading repository then returns refer-ences to salient objects and gives theclient information regarding the proper-ties of the services. The client thenchooses a server to contact for theneeded services.

CORBA also provides CORBAser-vices, which define system–level objectframeworks that extend the CORBAmodel, and CORBAfacilities, which pro-vide horizontal and vertical applicationframeworks used by business objects.Although quite important to the designand implementation of a successfulCORBA-compliant system, these facili-ties are not important in the use ofCORBA to support a robust client/server environment [Orfali et al.1996b].

4.1.2 Client/Server with DCOM. Mi-crosoft is touting DCOM, which firstshipped with WindowsNT 4.0, as thefuture model for Internet computing;DCOM manifests itself primarilythrough the use of ActiveX components,

Figure 6. Client/server computing using distributed objects. Communication between components(denoted by arrows) is facilitated through ORBs (which have been omitted for clarity).



which are DCOM objects.4 Furthermore,software releases from Microsoft (suchas Visual J11) reveal that Microsoft isintent on providing a workable platformon which to implement Java objects.The integration of Java with DCOMthrough Visual J11 is even greaterthan that of C11 and DCOM providedthrough Visual C11. This is particu-larly interesting in light of the fact thatC11 is the language originally in-tended to be used with DCOM. DCOMhas migrated from a system for binaryinteroperability to the more accepted(and needed) system of providing high-level bindings to popular languages.The bindings provided with Visual J11are strong enough so that ActiveXswritten in other languages can be madeto look like remote Java objects.

DCOM is like CORBA in that itcleanly separates interface from func-tionality using an IDL. Microsoft haschosen to use an IDL based on the Dis-tributed Computing Environment(DCE). The IDL is neither CORBA- norDCE-compliant; this severely limits thepotential for interoperability. In addi-tion, separate interface functionality forMicrosoft’s Object Linking and Embed-ding technology is provided using theObject Definition Language (ODL).5

DCOM does not support the tradi-

tional notion of an object. DCOM “ob-jects” do not have a state; rather, theyare collections of interfaces. One couldliken this to a collection of algorithms,suggesting that a DCOM “object” is in-herently not as powerful a computingmachine as a CORBA object [Wegner1997b]. When a reference to a DCOMobject is requested, the handle is arbi-trary; a subsequent request for thesame object may yield a different han-dle connecting the client with an equiv-alent interface. DCOM supports a regis-try of available interfaces for objects toreference, and even provides informa-tion on the meanings and types of pa-rameters that should accompany a ser-vice request.

The client/server contract can be ful-filled in DCOM by the use of objectinterfaces. As in CORBA, DCOM inter-faces make the implementation lan-guage and the location of objects trans-parent. This assumes that a languagebinding for the language in question isavailable. For a DCOM client to accessthe methods of an object, it must use avirtual lookup table to obtain a pointerto that function. Multiple virtual tablescan exist for each object and they can bemodified to make interfaces alterablewhile the application executes.

These differences from the traditionalnotion of an object may leave the readerwondering what a DCOM object reallyis. A DCOM object can best be describedas a software component supporting atleast one interface; no knowledge ofstate is provided. Since DCOM objectshave no unique object identification,there are no naming or trading services

4 Microsoft’s WindowsDNA initiative strives tofurther integrate DCOM with Web-based client/server models.5 OLE no longer refers to Object Linking andEmbedding but rather to any COM-based technol-ogy. The ODL support for Object Linking andEmbedding exists in order to ensure backwardscompatibility [Chappell 1996].

Figure 7. Sample DCOM IDL code defining the interface for ISpellChecker. The compiler generatesproxies and stubs along with other related code. The non-standard parameter types are required byCOM.



provided by the DCOM runtime. Sinceindividual objects cannot be referencedwhile they exist, persistence is not sup-ported, limiting the problem domainsfor which DCOM objects becomes a via-ble solution. Furthermore, since there isno way to identify objects, a client objectcannot request to be connected to agiven server; it can only ask to be con-nected to an arbitrary server supportingthe services needed. Since DCOM doesnot support multiple inheritance of in-terfaces (proven to be the purest modelfor interface composition in Wegner[1997b], DCOM objects cannot automat-ically support multiple interfaces. If anobject contains an object supporting agiven interface, then the containing ob-ject can tell requesting clients that itsupports that same interface; the callsmust be forwarded to the contained ob-ject. There are two ways to do so.

(1) Containment/Delegation: The con-taining object must request thesame service of its inner object asrequested of it. The top-level objectdelegates service requests to morecapable objects.

(2) Aggregation: This model directly ex-poses the object interfaces to re-questing clients when they ask forthe interface of the top-level object.Put another way, the top-level ob-ject presents the interfaces of itscomponent objects as its own. Thishas the side effect of allowing a cli-ent to communicate directly withthe objects contained by the top-level object. Performance and effi-ciency can benefit from such an ap-proach, but some flexibility, control,and encapsulation may be lost.

By providing only for the functionalitymandated by the notion of inheritanceand thus ignoring inheritance on a con-ceptual level, Microsoft limits users ofDCOM to a “flat” object world. In addi-tion, programmers are forced to use con-tainment in place of inheritance in or-der to reuse code. This limitation has ahost of theoretical and practical ramifi-

cations, which are beyond the scope ofthis paper.6

When a DCOM client needs a server,it issues a request that an object sup-porting the required interface be instan-tiated to make the interface available.As a result, all DCOM servers mustprovide for a class factory supporting aspecialized interface (IClassFactory)that instantiates the class. In addition,the server must tell the Windows regis-try which classes it supports; this oftentakes place when the server componentis first installed on a system. Numerousproblems with Windows registries makeit a poor model for advertising systemservices.7 A major disadvantage of theWindows model is that it does not ac-commodate “newly” supported clientsnicely (for example, compatible clients).

Using interface pointers, DCOM sup-ports transparent communication be-tween clients and remote server objects.The DCOM runtime does some behind-the-scenes work to ensure that the in-terface pointer is local to the invokingprocess (through the use of a proxy, ifnecessary), but the client’s view is of theperpetual availability of services. Whenproxies are created, they communicatewith stubs on the serving end. Thismodel is quite similar to the mechanismemployed by CORBA to provide loca-tion-independent access to objects.

Although Microsoft has taken manyliberties with the object model thatshould improve performance, bench-mark tests indicate otherwise: bench-marks incorporating network communi-cation and simple method invocationshow DCOM to be almost 20% slowerthan CORBA.8

6 These issues are treated adequately in mosttexts on software engineering and design.7 Most of these problems involve registry integ-rity. Because the Windows registry is used sooften, it is very susceptible to corruption.8 A simple benchmark involved two 120-Mhz Pen-tiums running WindowsNT Workstation 4.0 con-nected by a 10 Mb/s Ethernet LAN. The client(written in C11) invoked a method on a server(also written in C11) 1000 times and measuredthe average response time of remote pings. The



4.1.3 CORBA as the Dominant Model.With DCOM running only on Microsoftoperating systems, there is little ques-tion that CORBA is the more portablesystem.9 CORBA is now in its thirdgeneration, and the standards body gov-erning its evolution serves as assurancethat it will remain an open system. Incontrast, DCOM is currently a Win-dows-only technology (although therehave been some experimentation withporting the system to flavors of UNIX)and it is apparently governed by itsmaintainer, Microsoft. Several barriersto porting DCOM to other platforms ex-ist. For example, DCOM relies on theWindowsNT security model to providesystem security; it is unclear what willprovide security when DCOM is used onother platforms. In contrast, CORBAuses a universal security mechanismthat will work on all platforms, regard-less of operating-system-level security.

CORBA provides a superior objectmodel by supporting the foundations ofthe popular classical object model. By

supporting unique object references, ca-pabilities such as persistence are easilysupported by CORBA, allowing a wholedomain of specialized applications to le-verage this strength to provide morerobust end user services. Native statehandling provided by CORBA frees theclient from the burden of providing amanaged-state system to handle theneeds of interacting objects.

Support for legacy systems is essen-tial to the success of any new computingtechnology. CORBA provides seamlessintegration for the most popular objectoriented languages, and robust supportfor all languages. DCOM language sup-port is limited to Java, C, C11, andVisual Basic. CORBA hides the IDLfrom the programmer, whereas an un-derstanding of the DCOM IDL is essen-tial to DCOM programming.

Although CORBA is clearly a superiortechnology, one should never underesti-mate any technology backed by Mi-crosoft and its huge installed base andresource pool. However, the rest of theindustry, including giants such asHewlett Packard, IBM, Novell, and Ap-ple, along with quickly moving newcom-ers such as Netscape, Oracle, and Java-Soft, are rallying behind CORBA tomake it the distributed object standard.

DCOM setup gave an average execution time of3.9ms; the CORBA setup, which used the VisiBro-ker ORB, gave an execution time of 3.2ms.9 As of mid-1997, Microsoft has pledged to supportDCOM on the MacOS and on the most popularUNIX variants.

Figure 8. A typical DCOM component, showing the supported interfaces and mandatory class factoryand object creation capabilities.



4.2 Using Java For Client/ServerApplications

Client/server systems developed usingJava employ a model of interactionmore advanced than that offered byother languages. Software systems de-veloped in Java rely on applicationsthat have many component-like quali-ties. Using Java applications, one candistribute executable content as easilyas one can deliver traditional static con-tent.

Java supports a mobile code system;this makes it an excellent choice formeeting the needs of mobile agents,which need to share (or distribute) bothcode and data across multiple serversand clients. Mobile code is distinguishedfrom traditional application code in thatit is dynamically executed by an appli-cation that provides the run-time envi-ronment. In Java, the assisting applica-tion is quite often a Web browser orsome other stand-alone application, al-though operating systems are probablya better choice for this task. For code tobe considered mobile, it must be porta-ble, meaning the code can be run on avariety of platforms; code bound to aspecific machine architecture or operat-ing system is not very mobile. Becausethe security provided by the runtimevaries, mobile code systems must pro-vide security. Since Java applicationscan “roam” and are executable on anyclient machine, and since we would likeusers to be able to download and exe-cute programs without the threat ofharm to their computing environment,the mobile code system must protecthost resources such as memory andfiles. Other considerations for mobilecode systems are: mechanisms for load-ing, unloading, and discarding applica-tions, and a way to transfer applicationsto hosts in a manner that guaranteestheir integrity.

Java’s mobile code system is providedthrough bytecodes, which elegantlysolves the portability and security prob-lems. The bytecode system calls for pro-grams to be “compiled” until they are at

the point where they can run on a JavaVirtual Machine, which translates thebytecodes into actual machine instruc-tions on the fly. Certain factors, such asthe size of data types and the behaviorof arithmetic operators, are standard-ized across virtual machines to ensurethat a Java program executes in thesame manner on any machine.10 Beforethis translation and execution, the JavaVerifier checks all code scheduled to beexecuted for malicious code (such asforged references or access violations).Security is augmented by four other lev-els of verification, ranging from nativelanguage design features to regulatedaccess to system facilities.

Although Java is often compared toC11, it is quite different in many ways.Java supports only single inheritance ofimplementation, which solves many se-mantic problems arising in complex in-heritance hierarchies and allows an ob-ject to support multiple interfaces.Interface inheritance is not consideredharmful and is generally recognized asproviding a more clean and accurateobject model. Java interfaces are quitesimilar to CORBA IDL files in that theyboth specify the services available froman object without revealing its imple-mentation.

Namespace semantics are provided byJava packages. Packages allow dynamicclass linking with methods that can beoverridden at runtime. Java also pro-vides automatic garbage collection andarray-bounds checking; it does not allowpointers, enforces strong type checking,and treats exceptions as essential lan-guage constructs. Native support formulti-platform multithreading is pro-vided; some simple features to meetthread synchronization needs are alsoincluded. These language features as-sist developers writing client/servercomponents that must interoperate eas-ily and provide high degrees of securityand reliability.

10 Unfortunately, this works better in theory thanin practice; numerous incompatibilities betweenvirtual machines still exist.



Much of Java’s appeal comes from thecore classes that are part of any stan-dard Java implementation. Since muchof the application functionality is pro-vided externally, application sizes areminimized, and since a lot of “busy-work” code has already been written,debugged, and approved as multi-plat-form-compatible, program developmentis greatly simplified. Some of these pre-built classes are provided through pack-ages such as java.lang, java.io, and java.util, while other parts come fromestablished frameworks. Some coreframeworks relevant to client/servercomputing include:

—Java Applet Framework: Provides the“basics” needed for Java applets(small applications meant to be down-loaded from the Web and executedusually within a Web browser) suchas base objects, native types, threads,exceptions, stream and file support,sockets, generic data structures (hashtables, stacks, etc.), a portable GUIlayer (to support events), animation,and wave audio.

—Java Commerce Framework: Providessecure monetary transactions, includ-ing online purchasing and financialmanagement.

—Java Enterprise Framework: Providesobject- and database-access servicesfor distributed systems. Incorporatedhere are APIs that support Java-to-CORBA communication, Java-to-Javacommunication, and Java-to-Java-Da-tabase-Connectivity (very similar toODBC) communication.

—Java Server Framework: Simplifiesthe development of Internet serversby providing APIs specifying simpleand uniform access to servers. It alsosupports servlets, which are minia-ture servers that end users can deployon a network to handle simple clientrequests.

—Java Media Framework: Supports 2Dgraphics and animation, synchroniza-

tion services, and audio. It is beingextended to support MIDI, 3D graph-ics, telephony, conferencing, andvideo. Using the media framework al-lows applications with robust interac-tion semantics to work across multi-ple platforms with modification.

—Java Security Framework: Providessupport for authentication, digitalsignatures, and encryption.

—Java Beans Framework: Serves as acomponent model native to Java. Itextends the application model by al-lowing flexible event handling acrossmultiple components, discovery ofmethods supported by other objects,persistent objects, and user interfaceallocation among multiple objects.This framework is quite important asit allows objects on a Web page tocommunicate and occupy overlappingscreen areas.

These frameworks suggest that Java isnot simply a language but, rather, aportable object platform.

By introducing a new way to developapplications, Java has created a newparadigm for managing and deployingclient/server systems. By ensuringmulti-platform compatibility, Java al-lows a developer to deliver an applica-tion to millions of users through itsavailability for downloading from a Webserver. A formal installation procedureis not usually required, and updates areprovided by updating the single copy ofthe application on the Web server.Server technology also stands to benefitfrom Java, most notably from the use ofmobile code. With no modification to theapplication or its source code, serverscan start processes on any machine onthe network, and can move themselvesor their child processes to the most ap-propriate machine at any time. The po-tential for rapid application develop-ment also makes Java a good client/server programming language sinceeffective client/server development re-quires constant feedback from end users.



4.3 Client/Server Using Java and CORBA

Java has transformed the World WideWeb into an interactive system support-ing objects, but it is not a sufficientsolution to the problem of creatingtransparently interoperating objects forclient/server systems. However, whencoupled with distributed object technol-ogy, it forms a strong basis for the devel-opment of a robust system that supportsclient/server computing. A platform foruniversal network computing can becreated using Java as a programminglanguage and mobile code system andCORBA as an integration technology.

CORBA can replace the current Web-based system of providing client/serverservices, which uses HTTP/CGI. Doingthis would bring three significant bene-fits to Java.

(1) Superior performance and flexibil-ity: CORBA allows clients to invokemethods on a server directly, withparameters passed by precompiledstubs or generated dynamically.This system is more flexible thanthe system supported by HTTPsince the client component is notlimited to the predefined methodssupported by HTTP; any IDL-de-fined method can be invoked. In ad-dition, CORBA allows parameters ofany type to be passed, whereas CGIaccepts only strings as parameters.CORBA also avoids rerunning a pro-gram at each client request, and canstore state between client invoca-tions; CGI requires the program tobe executed for each request, and itdoes not support state.

(2) Scalability: The CORBA ORB candispatch incoming client requests toa server of its choosing, allowingload balancing of client requests(this is further facilitated by inter-server communication via the ORB).CGI applications have no way of dis-tributing client requests to otherservers; one CGI application musthandle all the requests it receives.

(3) Component infrastructure: Javadoes not provide native support formethod invocations across addressspaces, meaning that Java applica-tions cannot request services of re-mote Java objects. Using CORBAwould allow communication not onlyamong Java applications, but alsoamong Java applications and com-ponents written in other languages.Of course, CORBA would also sup-ply its standard component services,such as transactions and persis-tence.

Since it was designed to naturally sup-port three-tier client/server systems,CORBA is a natural extension to Java’sobject model that brings robust distri-bution services to Java objects. In manycases, using CORBA with Java wouldallow Java components to be split intoclient and server side components, mak-ing the Web client/server model evenmore attractive since download timewould decrease (only the client compo-nent would need to be downloaded).

Java can build on the strengths ofCORBA. By using CORBA to providenetwork transparency and Java to pro-vide implementation transparency, asystem that offers total transparency ofcomponents can be created. Some waysin which Java improves on CORBA in-clude:

—Simplified code distribution: UsingJava, code is easily deployed from acentral server for download on de-mand. This ensures that all updatesare “installed” (instead of requiringthat system administrators updateeach workstation manually).

—Mobile code: Using Java’s native mo-bile code capabilities, functionalitycan be moved dynamically betweenmachines or between the client andserver components of a system.

—Agenting: Since it is assumed thatevery machine visited by a roamingagent will have a Java virtual ma-chine installed on it, CORBA applica-tions requiring agents can use Java’s



mobile code system to move aroundbehavior, with CORBA providingstate persistence services and Javaproviding the behavior.

—Additional component services:CORBA defines “visual containers”(based on Apple Computer’s OpenDoc)for components, and Java applicationscan serve as the portable componentsthat exist within these containers.CORBA’s mobile container structure,based on OpenDoc’s “Bento” systemfor storing structured data, can beused as a mechanism for moving Javaagents around.

—Superior language features: Java iswell suited for writing robust clientand server code because of its nativemultithreading, garbage collection,and error management. Java workswell with CORBA since both systemsseparate interface from implementa-tion.

Java and CORBA complement eachother quite well, with CORBA providinga distributed object infrastructure andJava providing a strong mobile code sys-tem. Together, they let any two objectson the same network communicate un-der all circumstances.

5. FRAMEWORKS

A goal of object technology is the con-struction of software systems structuredin the same way as the analogous real-world systems. Frameworks are a toolto help programmers achieve this goal.

5.1 What Are Frameworks?

Frameworks typically provide a way tomanage a system of interacting objectsand to develop objects that will inte-grate seamlessly into the framework.Frequently, frameworks suggest pat-terns of collaboration between the ob-jects that constitute the framework, al-though a well designed frameworkallows flexible channels of collaborationthat suit the application at hand. Com-ponents that emerge from a finished

framework share consistent design at-tributes, and may even share commonimplementations. The benefit is a moremaintainable and consistent softwaresystem.

In contrast to the traditional ap-proaches to software reuse, which arebuilt on the paradigm of a set of librar-ies containing many small building-blocks, object-oriented frameworks al-low the highest common abstractionlevel between a number of similar sys-tems to be captured in terms of generalconcepts and structures. The result is ageneric design that can be instantiatedfor each object system constructed.

The framework is ideally suited forcapturing the elements common to afamily of related systems. In this sense,the framework is essentially a large de-sign pattern capturing the essence ofone specific kind of object system. Thebulk of the system functionality is cap-tured in the framework, which is main-tained as a single entity. Each softwaresystem using framework is an instantia-tion of that framework.

Frameworks provide a high degree ofdesign reuse for interactive systemscomposed of collaborating objects andensure that a “product” of the frame-work will work within it. Thus, frame-works are a valuable tool for ensuringthe availability of object services.

5.2 Business Objects as a Client/ServerFramework

Business objects are self-managing com-ponents used to represent key objects orprocesses in a real-life system. Businessobjects are “shippable” products thatusually have a user interface and theability to cooperate with other objects tomeet a certain user need. They can beused across single or multiple enter-prises. Business objects allow applica-tion-independent concepts to be de-scribed at a high level, minimizing theimportance of languages, tools, and ap-plication-level concepts. Business ob-jects represent a major breakthrough inthe modeling of business events since



they can describe both a portion of areal-world business system and the exe-cuting piece of the information systemsupporting that portion of the business[Orfali et al. 1996a; 1996b].

Perhaps the most significant advan-tage of using business objects is thecapability to model accurately the corre-sponding real-life business processes.Collaboration among business objects isessential to most robust systems sincefew business events involve only oneobject. For example, the task of billing acustomer involves the invoice, the pur-chaser, the goods being sold, and theseller. While some systems are modeledrelatively easily using basic objects,business objects allow collaboration at ahigher degree of semantic accuracy, re-ducing application development costs.When reengineering a business’s com-puter systems, the result of modelingshould be a high-level group of compo-nents that can be configured immedi-ately to run distributed across a net-work [Orfali et al. 1996b]. With thisinfrastructure in place, modeling anyevent affecting the business requiressimply the instantiation of a new busi-ness object. For example, if an order isplaced, a new invoice object must beinstantiated. This new object then hasits own life-cycle and could support it-self by collaborating with other objectsusing the underlying ORB. (It should benoted that “business objects” need notapply to business processes. Any systemrelying on concrete objects can be mod-

eled using business objects. A more ac-curate name would thus be “domain ob-jects;” however, the mainstream client/server community has adopted the termbusiness objects already.)

Like other components, business ob-jects should support late binding so theycan be interchanged easily and interactimmediately with existing components;they should also support standard com-ponent features such as event handlingand state maintenance. Business ob-jects are relatively easy to develop,since they can be based on CORBA ob-jects, which already provide a means forinter-component collaboration and re-source management. By using CORBAas a framework to construct businessobjects, much of the work of building arobust component is eliminated fromthe development cycle.

Business objects provide the samebenefits to system developers that tradi-tional objects provide; however, the ben-efits are specialized to a particular do-main. Business objects are reusable, sothe same invoice object can function inboth the accounts receivable and ship-ping portions of a company’s order man-agement system. In fact, the componentcould be shippable to the purchaser ofthe goods and also work with the ac-counts payable module of the purchas-er’s computer system. Business objectscan be specialized to meet the uniquedemands of a business. A business canpurchase an accounting package andthen specialize the invoice object to ac-

Figure 9. CORBA and business objects work together to provide client services.



commodate some special need, such asverifying the compatibility of items or-dered.

The Business Object Model SpecialInterest Group (BOMSIG) has proposeda standard for business objects. Thestandard calls for each business objectto be composed of three types of cooper-ating objects.

(1) Business Logic Object (BLO) defineshow the object reacts to certainevents; it is responsible for the busi-ness logic of the component as wellas for storing the relevant businessdata.

(2) Business Process Object (BPO) helpsmaintain the business logic for theentire system. The primary differ-ence between a BPO and a BLO isthe logical lifetime of the unit of logic:BPOs traditionally handle long-lived processes or processes relatedto the system as a whole.

(3) Presentation Objects provide theuser with a representation of thecomponent, usually but not neces-sarily visual.

A normal business object is likely tohave multiple Presentation Objects, butusually has one BLO and BPO. Becausethese three objects are managed by oneobject, collaborating components see

only one object that provides the aggre-gate services of its constituent objects.

This three-object construction can beviewed as a three tier client/server sys-tem.

—Tier 1: Visual aspects of a system,usually handled by a client system.

—Tier 2: Data for the object and theapplication logic required to meaning-fully act on it.

—Tier 3: Data and application logic re-quired to integrate the business objectwith other business objects and exist-ing systems, such as legacy servers ordatabases.

The middle tier plays the largest role inthis organizational scheme. Tier-two ob-jects communicate directly with thetier-one objects to provide feedback tothe user; they also provide the logic forthe entire business object. Furthermore,tier-two objects communicate with mul-tiple data repositories (tier three) andcollaborate with other business objectsto assist them provide services. Thismodel separates the client from data forwhich it is not logically responsible. Bychanneling all requests for informationthrough the tier-two servers, majorchanges (such as the implementation ofa new database system) remain com-pletely transparent to the user. If ORBs

Figure 10. The parts of a business object and their communication with other system objects [Orfali etal. 1996b].



are used for communication betweenthe clients and the tier-two objects, ro-bust system services such as load bal-ancing and event exchanges are imple-mented easily and applications remainscaleable.

The business object model works wellwith CORBA because CORBA allowsthe constituent objects to reside on anymachine. For example, the objects man-aging the business logic can reside on aserver, while the client-side Presenta-tion Object runs on a local workstation.This setup provides an inherent client/server relationship between compo-nents. Business objects can collaboratein a semantically and technically richmanner by using the facilities providedto every CORBA component. By lever-aging CORBA’s frameworks for datatransfer and collaboration and the pow-erful mobile code system provided byJava, business objects can interoperatein a stable manner, while allowing com-ponents to be added to or removed fromthe system. By keeping the frameworkfor collaboration fixed, the object life-cycle continues without affecting endusers.

5.3 Compound Documents as a ClientFramework

A compound document is a tool for orga-nizing components that serves as aframework for integrating the visualand containment relationships betweencooperating components. Compounddocuments can be composed of compo-nents from a wide variety of sources,

making them universally applicable.The familiarity of documents to end us-ers makes the compound document anobvious choice for introducing objecttechnology on a widespread basis. Theextension of the desktop metaphor,which incorporates application servicesand operating system services to pro-vide a seamless user experience, demon-strates the viability of such compounddocument systems.11

The compound document frameworkcalls for containers that can containcomponents. The containers themselvesare components; this allows recursivesystem construction. That is, a spelling-checker “container” can be constructedfrom dialog boxes, buttons, a dictionaryfile, and a database engine. This con-tainer can then become a component ina word processor, along with compo-nents for stylized text, graphics, gram-mar checking, and the like. Componentscan represent traditional programmingentities or common data types. In fact,any data type can be extended to be-come a component. By melding eachdata type into a component mold, com-pound documents accommodate all userdemands, since they can contain any-thing the user would like. Since data is

11 The most notable compound document systemis Apple’s now-canceled OpenDoc project; many ofthe concepts and principles of current compounddocument models are derived from this project.Interested readers are encouraged to examinesome of the literature available both online and inprint. For a fairly detailed introduction to Open-Doc, see Feiler and Meadow [1996].

Figure 11. Three tiers in a business object.



managed by its containing component,new data types can be added immedi-ately to documents; the document neednot know about the specific data type.

In order that components with no pre-existing knowledge of other componentsbe allowed to collaborate within a com-pound document, a system of communi-cation is required between the compo-nents managing a document’s data andthose managing the document itself.The component framework provides thiscommunication and manages shared re-sources, such as files and windows onthe user’s screen. A compound docu-ment framework is built on top of anobject bus, such as CORBA, which isbuilt from object services. The frame-work provides four core services to ob-jects serving as run-time members ofthe framework [Orfali et al. 1996b]:

(1) Document layout allows indepen-dent components to share a commondisplay area (usually a window).Components are required to collabo-rate via the document layout serviceto present themselves to the user.Once a display area is allocated,components that are also containersmust recursively allocate space tothe components they contain. Eachindividual component is responsiblefor interacting with the user anddisplaying its data in the space allo-cated to it. Containers distributeevents to the components they con-

tain and manage the resources theyshare.

(2) Structured storage. Since compounddocuments consist of many pieces ofdata managed by separate compo-nents, the storage needs of theframework are unique. A file storinga compound document consists ofseparate blocks of data, each man-aged by a component. Much like thedisplay, files must be partitionedinto spaces that each component cancontrol without adversely affectingother components. A recursivestructure similar to that used by thedocument layout manager is em-ployed. In addition to containingembedded data, files can also con-tain links to external data.

(3) Automation allows users to createtheir own relationships betweencomponents and to customize theirdocuments to create robust applica-tions. Scripts may replace tradi-tional code, allowing the client com-ponent of a client/server system tobe implemented as a compound doc-ument; intelligent active compounddocuments can also be crafted usingscripts [Wegner 1997a]. The possi-bilities for scripts are wide-ranging:password protection for documents,personalized document views, andactive data gathering are just a fewexamples. The use of scripts in con-junction with compound documents

Figure 12. The compound document framework uses the object framework (here CORBA) to takeadvantage of object services.



allows users to create documentsthat can manage themselves andare self-sufficient. Scripts may acti-vate upon user request or in re-sponse to the occurrence of a docu-ment or system-level event.

(4) Uniform data transfer (UDT). Cur-rent user environments allow datatransfer via the clipboard, linking,and drag-and-drop; compound docu-ments must do likewise, at the sametime taking into account the addedtechnical complexities of the newmetaphor. UDT provides a singlemechanism that works with thetransfer mechanisms mentioned andhandles containers intelligently bycopying not only the container itselfbut also its components.

Compound documents offer enhance-ments to older user interface meta-phors. Since it is possible to switch toany component immediately withoutlaunching a different application (usual-ly by clicking on it), editing multiplecomponents “simultaneously” is not asburdensome as in the current model,which requires users to switch applica-tions. Through this metaphor, compo-nents give the user the tools requiredfor the contained data in a context-sen-sitive way. Usability therefore im-proves, as positioning palettes next tothe data being edited instead of at some“default location,” and other such thingsare now allowed. The components of adocument are further integrated byeliminating the need for separate filesfor each document component. Every-thing a document contains is storedwithin a single file (links to the compo-nents can be maintained instead) sothat the user need not track the individ-ual items of data separately.

As compound document frameworksbecome embedded more seamlessly intothe operating system, everything a userdeals with will be considered a compo-nent. Initially, the transition from theWIMP user interface metaphor will notbe apparent. Users will still move fold-ers, and the files in them will follow.

But users will truly move components,which have more intelligence than to-day’s simple folders (which are reallyicons representing directories). Theywill be able to collaborate to share re-sources and accomplish complex taskstogether.

Compound documents have the poten-tial to usher in a new era of mobiledocuments. Mobile documents are ableto be edited, printed, and shared justlike regular documents. Their addedpower comes from the ability to exploitthe compound nature of the document.Since documents can contain executablecode, they can perform functions suchas routing themselves automatically. Inaddition, the document can contain notonly the salient data, but also the userinterface for the document, a record ofchanges to it, a method for controllingwho can access what portions of it, andother advanced functionality.

The compound document model canbe extended to create new user environ-ments. As compound documents beginto replace the traditional desktop meta-phor, collaborative environments tai-lored to real-world models can be con-structed. Different environments forchildren, doctors, and salespeople canform the basis of a person’s interactionswith local and remote services. Creatingsuch a virtual environment requiresmerely assembling a collection of com-ponents into a container document, sothe environment can be easily down-loaded by users who do not wish to crafttheir own environment. To accommo-date fee-based service access, companiescan charge to download an environ-ment. The environment alone wouldcontain the components needed totransact with the remote components,so non-paying consumers would be un-able to access the service. Once an envi-ronment has been constructed, it canserve as the client for all network ser-vices, including access to business ob-jects.

Compound documents provide aframework for Web browsing as theyare a visual component foundation for a



new generation of open Web browsersas well as a concrete container meta-phor for storing and distributing data.By downloading a pre-built compounddocument, a user has access to an en-tirely new and customized operating en-vironment. The use of compound docu-ments in place of the older models ofWeb browsing has several distinct ad-vantages. Compound documents inte-grate the visual experience by allowingcomponents on a Web page (includingJava applets or applications and tradi-tional content) to share window realestate and users to edit a component inplace without a separate application.New documents are created easily bycombining high-level components fromexisting documents in a new way. Themetaphor also allows a user to rear-range a Web “page” to his or her tastes.In addition, the components automati-cally share common menus, palettes,colors, and clipboards so the user expe-rience is seamless. Components can bedragged onto other components, or com-ponents can realize they are in the samedocument and work together to takesome action. Once Web documents be-come componentized, new methods ofdisplaying information will abound.

Because of its unique advantages, thecompound document model is likely tobecome a dominant force on the clientside in the growing client/server mar-ket. The model provides a convenientway of grouping related objects andmanages the difficulties of displaying,storing, and moving them via networks.Since a compound document maintainslinks to servers, it serves as a universalclient. Client applications can be builtwith ease by developers or end users byincorporating ready-made componentsand pre-written application logic, andthen customized for each individualuser. The user’s entire workspace canbe stored in one document if desired.

6. CONCLUSIONS

Distributed objects promise to revolu-tionize the stagnant client/server mar-

ket. CORBA’s object references providea clean way of gaining an object’s inter-face. Callbacks allow servers to controlclients and allow clients to receive newcontent to add to compound documents.In addition to its speed, the CORBAORB is interoperable with C11 objectsand integrates smoothly with Java. Bysupporting a three-tier client/serversystem, CORBA allows data from multi-ple sources to be encapsulated and poolsof servers to be created. The provisionsfor dynamic discovery of object inter-faces make CORBA components self-de-scribing, allowing flexible binding andeasy interoperation between compo-nents. The development of ubiquitousmiddleware available on all platformswill lead to true location transparency,and the fact that CORBA is an openstandard will ensure continued innova-tion and evolution of the system.

Leveraging CORBA and Java pro-vides the most notable advantages ofcomponent technology in the domain ofclient/server computing. CORBA workswell with Java applications, whichmake very good downloadable clientsbecause of their small size and Java’smobile code system. Using just-in-time(JIT) compilers, Java applications candeliver acceptable speed for all but themost demanding of client/server appli-cations, and as processors specializedfor Java are introduced, this perfor-mance will increase further. The Ab-stract Window Toolkit (AWT) providedwith Java allows multipanel applica-tions to be created easily and deployedunder a variety of windowing systemswith no need to rewrite UI-specific code.

Business processes can be modelednaturally and efficiently using distrib-uted objects. The interactive and collab-orative relationships between processesor business divisions can be modeledespecially well by business objects. Thepotential for the reuse of key portions ofbusiness objects can decrease develop-ment costs substantially, and the map-ping of business objects into a three-tier



client/server system brings many ad-vantages in the areas of efficiency andthe transparent integration of data.

Compound documents can serve as anew metaphor for the client-side of cli-ent/server applications and can beadapted to be the next generation ofWeb browsers. By leveraging the capa-bilities of cooperating components andthe component management facilities ofcompound documents, a new generationof active documents can change the wayin which client/server applications areviewed. The capability for interactionamong components within a documentwill drastically change the limits of cli-ent-side data manipulation. Compounddocuments can also form the basis fordynamic customizable user environ-ments crafted from components.

It is clear that components can usherin a new wave of client/server comput-ing that will bring new capabilities tothe masses. The only questions that re-main are: whether the superior technol-ogies reign over Microsoft’s well-fundedDCOM, and how soon ORBs will beintegrated at the operating systemlevel, creating a market environmentconducive to the development of manyinteractive components.

REFERENCES

ARNOLD, K., AND GOSLING, J. 1996. The JavaProgramming Language. Addison-Wesley,Reading, MA.

BROCKSCHMIDT, K. 1995. Inside OLE. 2nd ed.Microsoft Press, Redmond, WA.

CHAPPELL, D. 1996. Understanding ActiveX andOLE. Microsoft Press, Redmond, WA.

DOLGICER, M. 1997. Inside CORBA services. InApplication Development Trends (June), 63–71.

FEILER, J., AND MEADOW, A. 1996. EssentialOpenDoc. Addison Wesley, Reading, MA.

GAMMA, E., HELM, R., JOHNSON, R., AND VLISSIDES,J. 1995. Design Patterns: Elements of Reus-able Object-Oriented Software. Addison Wes-ley, Reading, MA.

GOSLING, J., AND MCGILTON, H. 1995. The JavaLanguage Environment: A White Paper. SunMicrosystems, Mountain View, CA.

GUTTMAN, M., AND OHNJEC, V. 1997. Distrib-uted object computing: the brave new world.In Application Development Trends (June),29–36.

JACOBSON, I., CHRISTERSON, M., JONSSON, P., AND

OVERGAARD, G. 1992. Object-Oriented Soft-ware Engineering: A Use-Case-Driven Ap-proach. Addison Wesley, Reading, MA.

ORFALI, R., HARKEY, D., AND EDWARDS, J.1996. The Essential Client/Server SurvivalGuide. John Wiley, New York.

ORFALI, R., HARKEY, D., AND EDWARDS,J. 1996. The Essential Distributed ObjectsSurvival Guide. John Wiley, New York.

RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY,F., AND LORENSEN, W. 1991. Object-Ori-ented Modeling and Design. Prentice Hall,Englewood Cliffs, NJ.

WEGNER, P. 1997. Frameworks For Active Com-pound Documents. Brown University Depart-ment of Computer Science, Providence, RI.

WEGNER, P. 1997. Why interaction is more pow-erful than algorithms. Commun. ACM (May),80–91.

Received June 1997; accepted October 1997

