the distributed object computing paradigm: concepts and applications

The distributed object computing paradigm:concepts and applications

Kassem Saleh a,b,*,1, Robert Probert b, Hassib Khanafer a

a Kuwait University, Department of Electrical and Computer Engineering, P.O. Box 5969, 13060 Safat, Kuwaitb University of Ottawa, School of Information Technology and Engineering, P.O. Box 450, Stn. A, Ottawa, Ont., Canada K1N 6N5

Abstract

The computing world is shifting toward a new paradigm, the Distributed Object Computing (DOC) paradigm. This paradigm

exploits the bene®ts of object-oriented technology and uses the Internet and its communications infrastructure as a vehicle for the

delivery of a wide range of sophisticated value-added distributed services. Applications of this paradigm are characterised as being

open, client/server and multi-tiered applications using collaborating distributed objects. The integration of the Common Object

Request Broker Architecture (CORBA) and object-oriented programming languages such as Java will facilitate the introduction and

deployment of such applications in a platform-independent distributed environment. In this paper, we introduce both CORBA and

Java as tools to facilitate the development of DOC-based applications, and we present examples from two areas of applications,

namely, telecom and electronic commerce (EC) applications. Ó 1999 Elsevier Science Inc. All rights reserved.

Keywords: CORBA; Distributed computing; Electronic commerce; Java; Object-orientation; Telecommunications

1. Introduction

The adoption of object-oriented technology is cur-rently a major trend in the software industry (Jacobson,1994). The basic component of this technology is theobject, a software component that encapsulates bothdata and code, and interacts with the outside worldthrough well-de®ned interfaces. This technology em-phasises the importance of reusability, maintainability,¯exibility and modularity in the software developmentprocess, thus enhancing the quality of the software andreducing its development cost, especially when amor-tized over several iterations.

Because of the rapid growth of network and internetusers, there is a high demand for the development ofhighly reliable and easily maintainable distributedcomputing software in a wide range of application do-mains, from tele-medicine to tele-education. These so-phisticated software applications are inherently complexin nature, and are further complicated by communica-tion, concurrency and synchronization issues.

From the marriage of object-oriented computing anddistributed computing comes the Distributed ObjectComputing (DOC) paradigm (Special issue on dis-tributed object computing, 1997). This paradigm ex-ploits the bene®ts of object-oriented technology and usesthe Internet and its communications infrastructure as avehicle for the delivery of a wide range of sophisticatedvalue-added distributed services. Applications of thisparadigm are characterised as open, client/server, multi-tiered and using collaborating distributed objects. Theintegration of the Common Object Request BrokerArchitecture (CORBA) (Orfali and Harkey, 1997) andobject-oriented programming languages such as Javawill facilitate the introduction and deployment of suchapplications in a platform-independent distributed en-vironment.

The telecommunication industry is one of the mainindustries investing in client/server and distributed ap-plications. The DOC paradigm has a great potential forintegrating di�erent telecommunication services includ-ing video, audio and data retrieval, and for the man-agement of heterogeneous computer networks. Anotheremerging industry that will involve the deployment ofcollaborating distributed objects is Electronic Com-merce or e-commerce.

In this paper, we ®rst introduce two important com-ponents of our strategy to facilitate the implementation

The Journal of Systems and Software 47 (1999) 125±131www.elsevier.com/locate/jss

* Corresponding author. Fax: +1-613-562-5185; e-mail:

[email protected] On a one-year sabbatical leave from Kuwait University, Depart-

ment of Electrical and Computer Engineering.

0164-1212/99/$ ± see front matter Ó 1999 Elsevier Science Inc. All rights reserved.

PII: S 0 1 6 4 - 1 2 1 2 ( 9 9 ) 0 0 0 3 2 - 1

of the DOC paradigm, namely, CORBA and Java.CORBA is considered to be a vehicle for performingtransparent, internet-based distributed computations.Java, an object-oriented programming language, pro-vides features supporting distributed object communi-cation and computing, such as Remote MethodInvocation (RMI) and servlets (Saleh, 1999). We thendiscuss the integrated DOC paradigm using two possibleapplication domains based on the integration of COR-BA and Java.

The rest of the paper is organized as follows. Sec-tion 2 provides some preliminary background on inter-net-based distributed computing and the Javaprogramming language. Section 3 introduces CORBA.Section 4 describes two possible applications drawnfrom the telecommunications and electronic commercedomains. Finally, in Section 5, we conclude the paperand discuss issues for future work.

2. Preliminaries

In this section, we provide some preliminary conceptsand background information on DOC and Java's sup-port for it.

Typical distributed object applications consist of co-operating objects. Some of them acting as clients re-questing services, others acting as servers providing theseservices, with the provision that the same object acting asa server could act as a client to another server andvice-versa. These objects may reside in the same processin the same machine, or in di�erent processes in the samemachine or in completely di�erent machines.

Typically, distributed applications are multi-tiered (3tiers or more). For example, the ®rst tier is normally thePresentation tier handling the interface with the user.The second tier o�ers functionality and connectivity (abridge between the ®rst and third tier) achieving thebusiness function and logic of the application. The thirdtier is the data tier (i.e., data storage) (Saleh, 1999).Hence, we are dealing with thin-clients with minimumresponsibilities (Graphical User Interface ± GUI andinput validation), connected to data storage through atier that contains the business logic.

These applications exploit the bene®ts of the object-oriented programming paradigm. The building objectsof these applications have a clear separation betweentheir interface and their implementation. Client objectswill only need to know the interface of their servers toaccess their services without any concern about the im-plementation of these services.

Moreover, distributed objects interoperate transpar-ently. A client object is not concerned about the locationof the server object. A client object invokes the opera-tions o�ered by a server object as if it is residing in thesame machine. Ideally, ®nding these objects in a dis-

tributed computing environment, and the involvedcommunication details should not be the responsibilityof the client. Similarly, the server object receives a re-quest, processes it and sends its reply to the clientwithout caring about the client's location and the com-munication details.

The internet is a perfect vehicle for delivering dis-tributed object applications and services. Millions ofheterogeneous computers are connected to the networkof networks (the web). The web provides a typical client/server architecture, in which a web browser is the clientand a web server is the server. However, the popularHTTP/HTML/CGI combination is fundamentally farfrom satisfying the requirements of distributed objectapplications.

The Java programming language, introduced by SunMicrosystems, is an object-oriented, multi-threaded andportable programming language, whose object modelcovers advanced features such as concurrency, mobilityand persistence (Farley, 1997). Java eliminates the in-e�ciencies of the HTTP/HTML/CGI combination andprovides the means for achieving distributed objectcomputations on the internet. Java introduced to theweb the concept of mobile agents. Using Java, a devel-oper can write an applet: a self-contained program in-stalled in a web server and integrated as part of a webpage. Once the browser requests an HTML ®le pointingto an applet, a TCP connection will be dedicated fordownloading the applet to the local host of the browser(i.e., client). A Java-enabled browser (which includes arun-time Java environment or virtual machine) will thenexecute the applet in the local host.

Moreover, Java mobile agents or applets are portableand platform-independent. Also, applets also o�er GUIfacilities that are more ¯exible than pure HTML pages,and they allow part of the application code to be exe-cuted at the client-side (such as input validation), re-lieving the server and reducing network tra�c.Furthermore, applets also reduce the cost incurred in thesoftware set-up and maintenance process. Code could beinstalled in the server and distributed across the networkwithout any e�ort from the programmer.

An important feature of Java is its Application Pro-gramming Interface (API) for executing SQL state-ments, called Java Database Connectivity (JDBC). ThisAPI consists of a set of classes and interfaces written inthe Java programming language (Saleh, 1999). UsingJDBC, programmers can write programs containingSQL statements that can access popular relational da-tabases, such as Oracle, Sybase, Microsoft Access andInformix. Transparent database access is a very impor-tant feature of real-time applications, especially appli-cations involving on-line access to data sources (e.g. adirectory for telephone service subscribers). This featurefacilitates the separation between the business logic(second tier) and the data (third tier). Moreover, this

126 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125±131

separation allows easy maintenance of the business logicand provides a transparent access to multi-platformdatabases.

Although Java is a big step toward deploying dis-tributed object along with the Internet and the web, yetit does not introduce an integrated distributed objectinfrastructure. Java does not o�er the mechanisms andservices needed to manage distributed objects. For ex-ample, Java does not address how a local client-objectcan invoke the method of a remote object, how thisserver-object can be found, collecting the results of re-quests, activation of remote objects, etc.

To overcome this shortcoming, Java introduced theRemote Method Invocation (RMI) class library tosupport the concept of cooperating distributed objects.However, RMI allows the interoperability of client andserver objects both written in Java. The interworkingwith objects written in other languages such as ADA,C++ and Smalltalk was not addressed in RMI. How-ever, this issue has been addressed by CORBA and isdiscussed in the next section.

3. CORBA

The Object Management Group (OMG), a consor-tium of 700+ software vendors, developers and users,introduced the Object Management Architecture(OMA), a high-level vision of a complete distributedenvironment. The OMA consists of four componentsthat can be roughly divided into two parts: system-ori-ented components (Object Request Broker and ObjectServices) and application-oriented components (appli-cation objects and common facilities) (Orfali and Har-key, 1997).

The most important component of this architecture isthe Object Request Broker (ORB). It allows objects tointeract in a platform- independent heterogeneous dis-tributed environment. ORBs take care of locating andactivating servers, marshalling requests and responses,handling concurrency and exception conditions. Thestandard adopted by OMG is called CORBA, whichspeci®es a system that provides interoperability betweenobjects in a heterogeneous distributed environment. Theservices used for developing distributed objects arecalled CORBAservices. Services intended for use pri-marily by distributed application objects are calledCORBAfacilities. Applications developed using theseservices are called Application objects.

The object model introduced in CORBA is describedas a group of cooperating objects that reside in the samemachine or in di�erent machines. The client side objectscan invoke methods of the server side objects (objectimplementation is the term used by CORBA to name theserver side objects) using its object reference (object ID),as it invokes the method of any other local object. Any

request will be intercepted and executed by the ORBwhich is responsible for locating the remote object anddelivering the request to it. The server object processesthe request and sends the result to the client again viathe ORB.

In this object model, the client object does not need toknow about the implementation of the server. Theserver o�ers just an interface which serves as a gatewayto its o�ered services. Consequently, there is a clearseparation between the interface and the implementa-tion of the objects. One important feature of CORBA isthat these cooperating objects could be written in dif-ferent languages such as Java, C, C++ and ADA.

To achieve such interoperability, CORBA intro-duces a strong typed, neutral and declarative language,called Interface De®nition Language (IDL). IDL issimilar to Java and C++ and can be mapped to manylanguages. The interfaces of interoperating objects arewritten in IDL. Then, using special compilers (ortranslator) the IDL interface is converted to Java, C++or any other language (provided the IDL compiler isavailable).

A client/server DOC-based application can be devel-oped using the following procedural steps:1. The interface of the server object is written in IDL.

This interface is actually a skeleton containing themethods which provide both the services of the serverobject and access to its instance variables. In thecode, we ®nd the signatures of methods but not theirimplementations.

2. The IDL code is compiled (mapped) to the languageof implementation using special compilers (such com-pilers exist for Java and C++). The compiler will pro-duce two types of classes: stub classes are linked tothe client-object code, and skeleton classes are linkedto the server-object code.

3. The implementation of the methods of the skeletonhas to be written in the language to which the IDLcode was mapped.

4. The codes of the client and server applicationshave to be compiled using the native language com-pilers.

After performing the above procedure, client and serverobjects are ready to invoke each other's methods. Theseobjects will be bound to di�erent client and server ap-plications.

Fig. 1 shows the interactions between client andserver objects (usually referred to as ORB invocation):

The ORB invocation can be summarized as follows:1. The client object calls a server method through the

stub (usually called Proxy object).2. The ORB hands the request to the BOA which acti-

vates the implementation (server object).3. The implementation invokes the BOA to say it is ac-

tive and available.

K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125±131 127

4. BOA passes the request to a method in an object im-plementation (server) via its skeleton.

5. The implementation returns the results back to theclient object through the ORB.

Basic Object Adapter (BOA) sits on top of the ORB'score communication services and accepts requests forservices on behalf of server objects. BOA provides therun-time environment needed for instantiating serverobjects, passing requests to them and assigning themobject Ids.

The stub and skeleton classes implement locationtransparency. Once instantiated, the server will be givenan object reference. Using that reference, the client canlocate the server through the ORB, without knowingwhere it resides.

The above method of invoking server methods iscalled static invocation. Clients can use a facility o�eredby CORBA architecture, called the Interface repository,to make dynamic invocation. At run-time, the client canaccess the Interface repository to determine the availableobjects, their interface and their parameters and form arequest on-the-¯y. While static invocation is character-ized by its ease of programming, dynamic invocation is¯exible but hard to program, and is used when theavailable objects and their interfaces are not known atcompile time.

The standard communication protocol, the ORB usesfor communication between distributed objects runningon the internet is the Internet Inter-ORB protocol (IIOP).IIOP is an application protocol that runs on top of TCP/IP. In contrast to the stateless HTTP, IIOP can preservethe state of the sessions. It can also handle multiple re-quests per session. Once the connection is establishedbetween CORBA objects, messages do not go throughthe web server. Unlike the bottleneck in the CGI/HTTPcase, all inter-object communications are performed di-rectly between the objects using IIOP.

Other CORBA features that are characteristics ofdistributed object technology include: (1) freeing pro-grammers from network programming, where they nolonger have to worry about low level networking details(Saleh, 1999); (2) multi-threading of clients and servers,and (3) the introduction of callback objects. A clientobject who needs a feedback does not have to wait for

the server reply. Alternatively, it can create a callbackobject (a separate thread), submit the callback objectreference to the server and continue executing its tasks.Once the server is ready, it forwards its reply to thecallback object.

Java and CORBA complement each other. Eacho�ers the other the service it lacks and together supporta computing world made of objects running in a het-erogeneous environment and interoperating transpar-ently. While Java o�ers CORBA its mobile agents(applets) that can be written once and run every where,its strong security model and multi-threading facilities,CORBA o�ers Java the needed distributed objects in-frastructure.

Using Java and CORBA, the interaction scenariosbetween browsers and web severs are as follows:1. The browser requests an HTML page from the web

server. Using HTTP, the page and its embedded ap-plet will be downloaded into the browser.

2. The local Java run-time environment of the browserexecutes the applet.

3. If the applet needs to invoke the methods of remoteobjects, it will use the client ORB which will commu-nicate with the server ORB using IIOP protocol. Theweb server will not be involved during this interac-tion. The server object will receive the requestthrough its ORB, and if it can satisfy it, it formulatesa reply and sends it back through its ORB. UsingIIOP, the reply is forwarded to the client throughits ORB.

Clearly, CORBA provides a better support for DOCthan Java's RMI and HTTP/CGI. In addition, CORBAretains its superiority over DCOM, Microsoft's mid-dleware for distributed objects, due to its wide supportin the industry, platform heterogeneity, maturity, lesscomplexity and rich set of object services (Orfali andHarkey, 1997).

4. Applications

In this section, we brie¯y describe the integration ofJava and CORBA in two applications. Our aim is toshow how both components, Java and CORBA, can beused to support the DOC paradigm in two di�erentdomains (Saleh et al., 1999). The use of Java applets andCORBA in multi-user distributed applications was alsodescribed in Evans and Rogers (1997).

4.1. Distributed object computing in a telecom application

The internet/web and CORBA/Java are consideredideal vehicles for delivering various telecommunicationservices, such as telephony services, faxes and videoconferencing. This is due to the fast growth of the in-

Fig. 1. Client server object interactions in CORBA.


ternet community, the increase of the available band-width due to the introduction of new networkingtechnologies (such as ATM), the widespread use ofWWW, the DOC infrastructure introduced by COR-BA/Java, the ease of programming using Java and theintroduction of Java APIs, that handle di�erent kindsof media.

In the following, we introduce a client/server appli-cation that implements a primitive telephone exchangeusing CORBA/Java over the web. An informal de-scription of this application was introduced in (Ja-cobson, 1994). In this application, we have three majoractors: the telephone exchange, subscribers and the op-erator. The subscribers are parties that call each other bystarting a calling session. The telephone exchange is re-sponsible for establishing a dedicated network connec-tion between the subscribers for each calling session.Operators are superusers who access the exchange tomonitor the tra�c in the network, and to review andupdate subscribers' information.

In this application, all subscribers' information isstored in a relational database. Subscribers can be calledor calling parties. They are implemented as multi-threaded Java applets. When an applet makes a call toanother applet (starting a calling session,) it acts as aclient to the exchange, but when the applet is receivingprobes and data from the exchange, it acts as a server tothe exchange. Each applet contains a callback objectrunning in a high priority thread and listening contin-uously to the exchange messages, thus allowing the ap-plet to act as a server.

The telephone exchange consists of three servers: thedatabase server, the time server and the coordinator.Each server is instantiated in a separate active process,and includes methods exposed to all subscribers. Theserver objects are not processes with in®nite loops butshared objects with multi-threading capabilities (by de-fault) and without any e�ort from the programmer.

The database server is responsible for maintaining apermanent connection to the database using the JDBC-ODBC bridge. Any object that needs to review andmanipulate information in the database has to call themethods of this object. Clients of this object are sub-scribers and operators. The validity of a subscriber'suser id and password is veri®ed using this server. Fur-thermore, the Operator needs to review and update thesubscribers' information stored in the database.

The time server object is responsible for timing theduration of terminating calls for accounting purposes.Using the services of this object, time is recorded at thestartup and termination yielding the session duration.

The coordinator is the backbone of the exchange. Itsresponsibilities range from registering the active sub-scribers once they are guaranteed access to the ex-change, establishing a permanent connection betweensubscribers once the called party is ready to receive the

call, transfer the talk between the two parties of thecalling session, and compute the time duration ofthe calling sessions. The coordinator maintains tworegistries, one for all the active users and the other onefor the active calling sessions.

The operator is implemented as a multi-threaded Javaapplet that has the ability to add new subscribers tothe RDBMS, review subscribers' information, monitorthe active calling sessions in the network, and monitorthe tra�c on the other server objects.

Fig. 2 shows a high level architectural view of thetelecom application including all interacting objects de-scribed above. Fig. 3 shows the di�erent actors in thesystem and their interactions using the IIOP of CORBAas the transport mechanism.

The object-oriented design and implementation of thetelecom application is described in detail in Saleh andKhanafer, submitted.

Although the distributed object-oriented design al-lows the transparent distribution of objects all over thenetwork, objects can be colocated for convenience. Forexample, the time server, database server and coordi-

Fig. 2. Architectural view of telecom objects and their interactions.

Fig. 3. The distributed objects of the telecom application.


nator objects can coexist in the same internet node orcomputer. Also, objects can be written in di�erent pro-gramming languages. For example, we can have the timeserver object written in C++.

4.2. Distributed object computing in an electronic com-merce application

Electronic Commerce (EC) systems are considered asspecialized instances of distributed processing systems(Saleh and Probert, 1998). As for any distributed sys-tem, an EC system is architecturally composed of mul-tiple, decentralized and autonomous processing entitiesor agents exchanging messages across the network. ECsystems are also reactive, real-time, concurrent and opensystems. Basically, an EC software system providesmany functionalities that are distributed among severalbusiness areas. The degree of distribution and com-plexity varies among these areas. These areas may in-clude product cataloging, advertising and marketing,order execution and post-order support and manage-ment.

A typical EC system requires the collaboration ofseveral entities (or agents) to complete an order trans-action. The orderly and timely exchange of messagesamong those agents ensures the correct execution of anEC transaction. These agents are, in addition to theconsumer and business, the ®nancial institution, thepayment server, the shipper and the supplier.

Because of the distributed nature of this applica-tion, it seems intuitive to have an object acting onbehalf of each of the collaborating agents listed above.Using CORBA's ORBs as a secure delivery platformfor this application, distributed objects can collaborateto successfully complete the requested business func-tion.

Fig. 4 shows the di�erent actors in the system usingthe IIOP as the transport mechanism. As in the previousexample, some objects can be colocated and written indi�erent languages.

5. Conclusions

From the exploitation of object-oriented and dis-tributed computing technologies, a new and promising

computing paradigm emerged: the DOC paradigm. Awide variety of sophisticated value-added internet ap-plications can be developed based on this paradigm,such as EC, telecommunication services and networkmanagement.

Although there are many candidate tools that facili-tate the development and deployment of such applica-tions, CORBA and Java are gaining popularity in thecomputer software industry. While Java o�ers intelli-gent, multi-threaded, portable and mobile objects,CORBA o�ers the infrastructure that allows these ob-jects to communicate and interoperate in a transparentmanner.

We are currently working on facilitating the de-scription of DOC applications design using existing andemerging design notations for object-oriented systemssuch as the Uni®ed Modeling Language (UML).

Acknowledgements

The authors would like to thank the reviewers fortheir comments. Also, the authors would like to ac-knowledge the support of this work by a Kuwait Uni-versity Research Administration Grant EE-107 and aGrant from the Natural Sciences and Engineering Re-search Council (NSERC) of Canada.

References

Evans, E., Rogers, D., 1997. Using java applets and CORBA for multi-

user distributed application. IEEE Internet computing.

Farley, J., 1997. Java distributed computing. O'Reilly.

Jacobson, I., 1994. Object-Oriented Software Engineering: A Use Case

Driven Approach, 4th ed. Addison-Wesley, Reading, MA.

Orfali, R., Harkey, D., 1997. Client/Server programming with Java

and CORBA. Wiley, New York.

Saleh, K., 1999. Java object model: elements and application. Journal

of Information and Software Technology, 41 (4), 235±241.

Saleh, K., Khanafer, H., Probert, R., Ural, H., 1999. CORBA-based

telecom application of distributed object computing. Proceedings

of the 17th IASTED International Conference on Applied

Informatics (AI'99), Innsbruck, Austria.

Saleh, K., Khanafer, H. Object-Oriented Design and Implementation

of a Telecom Application Using Java and CORBA, submitted .

Saleh, K., Probert, R., 1998. Issues in testing electronic commerce

systems, First IBM International Workshop on Technological

Challenges in Electronic Commerce, Toronto, Canada.

Special issue on distributed object computing, 1997. IEEE Commu-

nications Magazine 35 (2).

Kassem Saleh received a B.Sc., M.Sc. and Ph.D. from the Universityof Ottawa in Canada in 1985, 1986 and 1991, respectively. He workedat Bell Canada from 1985 to 1991 and Concordia University for oneyear before joining Kuwait University in 1992. He is currently anAssociate Professor in the Department of Electrical and ComputerEngineering, College of Engineering and Petroleum at Kuwait Uni-versity. Dr. Saleh was placed in eighth position among the topscholars in the Field of Systems and Software Engineering in anannual assessment published by the Journal of Systems and Softwarein October 1997 and October 1998. He was awarded the distinguishedteacher prize in 1996 both from the College of Engineering and

Fig. 4. The distributed objects of an EC application.


Petroleum at Kuwait University. Dr. Saleh serves on the editorialadvisory board of the Computer Communications journal. His cur-rent research and teaching activities are in software engineering,

communications software, distributed systems and internet comput-ing. Dr. Saleh has presented many tutorials at international confer-ences and universities worldwide.


the distributed object computing paradigm: concepts and applications

Documents