The distributed object computing paradigm: concepts and applications

Transcription

1 The Journal of Systems and Software 47 (1999) 125±131 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, Safat, Kuwait b 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 currently a major trend in the software industry (Jacobson, 1994). The basic component of this technology is the object, a software component that encapsulates both data and code, and interacts with the outside world through well-de ned interfaces. This technology emphasises the importance of reusability, maintainability, exibility and modularity in the software development process, thus enhancing the quality of the software and reducing its development cost, especially when amortized over several iterations. Because of the rapid growth of network and internet users, there is a high demand for the development of highly reliable and easily maintainable distributed computing software in a wide range of application domains, from tele-medicine to tele-education. These sophisticated software applications are inherently complex in nature, and are further complicated by communication, concurrency and synchronization issues. * Corresponding author. Fax: ; ksaleh@site.uottawa.ca 1 On a one-year sabbatical leave from Kuwait University, Department of Electrical and Computer Engineering. From the marriage of object-oriented computing and distributed computing comes the Distributed Object Computing (DOC) paradigm (Special issue on distributed object computing, 1997). 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 open, client/server, multitiered and using collaborating distributed objects. The integration of the Common Object Request Broker Architecture (CORBA) (Orfali and Harkey, 1997) and object-oriented programming languages such as Java will facilitate the introduction and deployment of such applications in a platform-independent distributed environment. The telecommunication industry is one of the main industries investing in client/server and distributed applications. The DOC paradigm has a great potential for integrating di erent telecommunication services including video, audio and data retrieval, and for the management of heterogeneous computer networks. Another emerging industry that will involve the deployment of collaborating distributed objects is Electronic Commerce or e-commerce. In this paper, we rst introduce two important components of our strategy to facilitate the implementation /99/$ ± see front matter Ó 1999 Elsevier Science Inc. All rights reserved. PII: S ( 9 9 )

2 126 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125±131 of the DOC paradigm, namely, CORBA and Java. CORBA is considered to be a vehicle for performing transparent, internet-based distributed computations. Java, an object-oriented programming language, provides features supporting distributed object communication and computing, such as Remote Method Invocation (RMI) and servlets (Saleh, 1999). We then discuss the integrated DOC paradigm using two possible application domains based on the integration of COR- BA and Java. The rest of the paper is organized as follows. Section 2 provides some preliminary background on internet-based distributed computing and the Java programming language. Section 3 introduces CORBA. Section 4 describes two possible applications drawn from the telecommunications and electronic commerce domains. Finally, in Section 5, we conclude the paper and discuss issues for future work. 2. Preliminaries In this section, we provide some preliminary concepts and background information on DOC and Java's support for it. Typical distributed object applications consist of cooperating objects. Some of them acting as clients requesting services, others acting as servers providing these services, with the provision that the same object acting as a server could act as a client to another server and vice-versa. These objects may reside in the same process in the same machine, or in di erent processes in the same machine or in completely di erent machines. Typically, distributed applications are multi-tiered (3 tiers or more). For example, the rst tier is normally the Presentation tier handling the interface with the user. The second tier o ers functionality and connectivity (a bridge between the rst and third tier) achieving the business function and logic of the application. The third tier is the data tier (i.e., data storage) (Saleh, 1999). Hence, we are dealing with thin-clients with minimum responsibilities (Graphical User Interface ± GUI and input validation), connected to data storage through a tier that contains the business logic. These applications exploit the bene ts of the objectoriented programming paradigm. The building objects of these applications have a clear separation between their interface and their implementation. Client objects will only need to know the interface of their servers to access their services without any concern about the implementation of these services. Moreover, distributed objects interoperate transparently. A client object is not concerned about the location of the server object. A client object invokes the operations o ered by a server object as if it is residing in the same machine. Ideally, nding these objects in a distributed computing environment, and the involved communication details should not be the responsibility of the client. Similarly, the server object receives a request, processes it and sends its reply to the client without caring about the client's location and the communication details. The internet is a perfect vehicle for delivering distributed object applications and services. Millions of heterogeneous computers are connected to the network of networks (the web). The web provides a typical client/ server architecture, in which a web browser is the client and a web server is the server. However, the popular HTTP/HTML/CGI combination is fundamentally far from satisfying the requirements of distributed object applications. The Java programming language, introduced by Sun Microsystems, is an object-oriented, multi-threaded and portable programming language, whose object model covers advanced features such as concurrency, mobility and persistence (Farley, 1997). Java eliminates the ine ciencies of the HTTP/HTML/CGI combination and provides the means for achieving distributed object computations on the internet. Java introduced to the web the concept of mobile agents. Using Java, a developer can write an applet: a self-contained program installed in a web server and integrated as part of a web page. Once the browser requests an HTML le pointing to an applet, a TCP connection will be dedicated for downloading the applet to the local host of the browser (i.e., client). A Java-enabled browser (which includes a run-time Java environment or virtual machine) will then execute the applet in the local host. Moreover, Java mobile agents or applets are portable and platform-independent. Also, applets also o er GUI facilities that are more exible than pure HTML pages, and they allow part of the application code to be executed at the client-side (such as input validation), relieving the server and reducing network tra c. Furthermore, applets also reduce the cost incurred in the software set-up and maintenance process. Code could be installed in the server and distributed across the network without any e ort from the programmer. An important feature of Java is its Application Programming Interface (API) for executing SQL statements, called Java Database Connectivity (JDBC). This API consists of a set of classes and interfaces written in the Java programming language (Saleh, 1999). Using JDBC, programmers can write programs containing SQL statements that can access popular relational databases, such as Oracle, Sybase, Microsoft Access and Informix. Transparent database access is a very important feature of real-time applications, especially applications involving on-line access to data sources (e.g. a directory for telephone service subscribers). This feature facilitates the separation between the business logic (second tier) and the data (third tier). Moreover, this

3 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125± separation allows easy maintenance of the business logic and provides a transparent access to multi-platform databases. Although Java is a big step toward deploying distributed object along with the Internet and the web, yet it does not introduce an integrated distributed object infrastructure. Java does not o er the mechanisms and services needed to manage distributed objects. For example, Java does not address how a local client-object can invoke the method of a remote object, how this server-object can be found, collecting the results of requests, activation of remote objects, etc. To overcome this shortcoming, Java introduced the Remote Method Invocation (RMI) class library to support the concept of cooperating distributed objects. However, RMI allows the interoperability of client and server objects both written in Java. The interworking with objects written in other languages such as ADA, C++ and Smalltalk was not addressed in RMI. However, this issue has been addressed by CORBA and is discussed in the next section. 3. CORBA The Object Management Group (OMG), a consortium of 700+ software vendors, developers and users, introduced the Object Management Architecture (OMA), a high-level vision of a complete distributed environment. The OMA consists of four components that can be roughly divided into two parts: system-oriented components (Object Request Broker and Object Services) and application-oriented components (application objects and common facilities) (Orfali and Harkey, 1997). The most important component of this architecture is the Object Request Broker (ORB). It allows objects to interact in a platform- independent heterogeneous distributed environment. ORBs take care of locating and activating servers, marshalling requests and responses, handling concurrency and exception conditions. The standard adopted by OMG is called CORBA, which speci es a system that provides interoperability between objects in a heterogeneous distributed environment. The services used for developing distributed objects are called CORBAservices. Services intended for use primarily by distributed application objects are called CORBAfacilities. Applications developed using these services are called Application objects. The object model introduced in CORBA is described as a group of cooperating objects that reside in the same machine or in di erent machines. The client side objects can invoke methods of the server side objects (object implementation is the term used by CORBA to name the server 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 ORB which is responsible for locating the remote object and delivering the request to it. The server object processes the request and sends the result to the client again via the ORB. In this object model, the client object does not need to know about the implementation of the server. The server o ers just an interface which serves as a gateway to its o ered services. Consequently, there is a clear separation between the interface and the implementation of the objects. One important feature of CORBA is that these cooperating objects could be written in different languages such as Java, C, C++ and ADA. To achieve such interoperability, CORBA introduces a strong typed, neutral and declarative language, called Interface De nition Language (IDL). IDL is similar to Java and C++ and can be mapped to many languages. The interfaces of interoperating objects are written in IDL. Then, using special compilers (or translator) the IDL interface is converted to Java, C++ or any other language (provided the IDL compiler is available). A client/server DOC-based application can be developed using the following procedural steps: 1. The interface of the server object is written in IDL. This interface is actually a skeleton containing the methods which provide both the services of the server object and access to its instance variables. In the code, we nd the signatures of methods but not their implementations. 2. The IDL code is compiled (mapped) to the language of implementation using special compilers (such compilers exist for Java and C++). The compiler will produce two types of classes: stub classes are linked to the client-object code, and skeleton classes are linked to the server-object code. 3. The implementation of the methods of the skeleton has to be written in the language to which the IDL code was mapped. 4. The codes of the client and server applications have to be compiled using the native language compilers. After performing the above procedure, client and server objects are ready to invoke each other's methods. These objects will be bound to di erent client and server applications. Fig. 1 shows the interactions between client and server 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 activates the implementation (server object). 3. The implementation invokes the BOA to say it is active and available.

4 128 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125±131 Fig. 1. Client server object interactions in CORBA. 4. BOA passes the request to a method in an object implementation (server) via its skeleton. 5. The implementation returns the results back to the client object through the ORB. Basic Object Adapter (BOA) sits on top of the ORB's core communication services and accepts requests for services on behalf of server objects. BOA provides the run-time environment needed for instantiating server objects, passing requests to them and assigning them object Ids. The stub and skeleton classes implement location transparency. Once instantiated, the server will be given an object reference. Using that reference, the client can locate the server through the ORB, without knowing where it resides. The above method of invoking server methods is called static invocation. Clients can use a facility o ered by CORBA architecture, called the Interface repository, to make dynamic invocation. At run-time, the client can access the Interface repository to determine the available objects, their interface and their parameters and form a request on-the- y. While static invocation is characterized by its ease of programming, dynamic invocation is exible but hard to program, and is used when the available objects and their interfaces are not known at compile time. The standard communication protocol, the ORB uses for communication between distributed objects running on 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 preserve the state of the sessions. It can also handle multiple requests per session. Once the connection is established between CORBA objects, messages do not go through the web server. Unlike the bottleneck in the CGI/HTTP case, all inter-object communications are performed directly between the objects using IIOP. Other CORBA features that are characteristics of distributed object technology include: (1) freeing programmers from network programming, where they no longer 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 client object who needs a feedback does not have to wait for the server reply. Alternatively, it can create a callback object (a separate thread), submit the callback object reference to the server and continue executing its tasks. Once the server is ready, it forwards its reply to the callback object. Java and CORBA complement each other. Each o ers the other the service it lacks and together support a computing world made of objects running in a heterogeneous environment and interoperating transparently. 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 infrastructure. Using Java and CORBA, the interaction scenarios between 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 applet will be downloaded into the browser. 2. The local Java run-time environment of the browser executes the applet. 3. If the applet needs to invoke the methods of remote objects, it will use the client ORB which will communicate with the server ORB using IIOP protocol. The web server will not be involved during this interaction. The server object will receive the request through its ORB, and if it can satisfy it, it formulates a reply and sends it back through its ORB. Using IIOP, the reply is forwarded to the client through its ORB. Clearly, CORBA provides a better support for DOC than Java's RMI and HTTP/CGI. In addition, CORBA retains its superiority over DCOM, Microsoft's middleware for distributed objects, due to its wide support in the industry, platform heterogeneity, maturity, less complexity and rich set of object services (Orfali and Harkey, 1997). 4. Applications In this section, we brie y describe the integration of Java and CORBA in two applications. Our aim is to show how both components, Java and CORBA, can be used to support the DOC paradigm in two di erent domains (Saleh et al., 1999). The use of Java applets and CORBA in multi-user distributed applications was also described in Evans and Rogers (1997) Distributed object computing in a telecom application The internet/web and CORBA/Java are considered ideal vehicles for delivering various telecommunication services, such as telephony services, faxes and video conferencing. This is due to the fast growth of the in-

5 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125± ternet community, the increase of the available bandwidth due to the introduction of new networking technologies (such as ATM), the widespread use of WWW, the DOC infrastructure introduced by COR- BA/Java, the ease of programming using Java and the introduction of Java APIs, that handle di erent kinds of media. In the following, we introduce a client/server application that implements a primitive telephone exchange using CORBA/Java over the web. An informal description of this application was introduced in (Jacobson, 1994). In this application, we have three major actors: the telephone exchange, subscribers and the operator. The subscribers are parties that call each other by starting a calling session. The telephone exchange is responsible for establishing a dedicated network connection between the subscribers for each calling session. Operators are superusers who access the exchange to monitor the tra c in the network, and to review and update subscribers' information. In this application, all subscribers' information is stored in a relational database. Subscribers can be called or calling parties. They are implemented as multithreaded Java applets. When an applet makes a call to another applet (starting a calling session,) it acts as a client to the exchange, but when the applet is receiving probes and data from the exchange, it acts as a server to the exchange. Each applet contains a callback object running in a high priority thread and listening continuously to the exchange messages, thus allowing the applet to act as a server. The telephone exchange consists of three servers: the database server, the time server and the coordinator. Each server is instantiated in a separate active process, and includes methods exposed to all subscribers. The server objects are not processes with in nite loops but shared objects with multi-threading capabilities (by default) and without any e ort from the programmer. The database server is responsible for maintaining a permanent connection to the database using the JDBC- ODBC bridge. Any object that needs to review and manipulate information in the database has to call the methods of this object. Clients of this object are subscribers and operators. The validity of a subscriber's user id and password is veri ed using this server. Furthermore, the Operator needs to review and update the subscribers' information stored in the database. The time server object is responsible for timing the duration of terminating calls for accounting purposes. Using the services of this object, time is recorded at the startup and termination yielding the session duration. The coordinator is the backbone of the exchange. Its responsibilities range from registering the active subscribers once they are guaranteed access to the exchange, establishing a permanent connection between subscribers once the called party is ready to receive the call, transfer the talk between the two parties of the calling session, and compute the time duration of the calling sessions. The coordinator maintains two registries, one for all the active users and the other one for the active calling sessions. The operator is implemented as a multi-threaded Java applet that has the ability to add new subscribers to the RDBMS, review subscribers' information, monitor the active calling sessions in the network, and monitor the tra c on the other server objects. Fig. 2 shows a high level architectural view of the telecom application including all interacting objects described above. Fig. 3 shows the di erent actors in the system and their interactions using the IIOP of CORBA as the transport mechanism. The object-oriented design and implementation of the telecom application is described in detail in Saleh and Khanafer, submitted. Although the distributed object-oriented design allows the transparent distribution of objects all over the network, objects can be colocated for convenience. For example, 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.

6 130 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125±131 Fig. 4. The distributed objects of an EC application. nator objects can coexist in the same internet node or computer. Also, objects can be written in di erent programming languages. For example, we can have the time server object written in C Distributed object computing in an electronic commerce application Electronic Commerce (EC) systems are considered as specialized instances of distributed processing systems (Saleh and Probert, 1998). As for any distributed system, an EC system is architecturally composed of multiple, decentralized and autonomous processing entities or agents exchanging messages across the network. EC systems are also reactive, real-time, concurrent and open systems. Basically, an EC software system provides many functionalities that are distributed among several business areas. The degree of distribution and complexity varies among these areas. These areas may include product cataloging, advertising and marketing, order execution and post-order support and management. A typical EC system requires the collaboration of several entities (or agents) to complete an order transaction. The orderly and timely exchange of messages among those agents ensures the correct execution of an EC transaction. These agents are, in addition to the consumer and business, the nancial institution, the payment server, the shipper and the supplier. Because of the distributed nature of this application, it seems intuitive to have an object acting on behalf of each of the collaborating agents listed above. Using CORBA's ORBs as a secure delivery platform for this application, distributed objects can collaborate to successfully complete the requested business function. Fig. 4 shows the di erent actors in the system using the IIOP as the transport mechanism. As in the previous example, some objects can be colocated and written in di erent languages. 5. Conclusions From the exploitation of object-oriented and distributed computing technologies, a new and promising computing paradigm emerged: the DOC paradigm. A wide variety of sophisticated value-added internet applications can be developed based on this paradigm, such as EC, telecommunication services and network management. Although there are many candidate tools that facilitate the development and deployment of such applications, CORBA and Java are gaining popularity in the computer software industry. While Java o ers intelligent, multi-threaded, portable and mobile objects, CORBA o ers the infrastructure that allows these objects to communicate and interoperate in a transparent manner. We are currently working on facilitating the description of DOC applications design using existing and emerging design notations for object-oriented systems such as the Uni ed Modeling Language (UML). Acknowledgements The authors would like to thank the reviewers for their comments. Also, the authors would like to acknowledge the support of this work by a Kuwait University Research Administration Grant EE-107 and a Grant from the Natural Sciences and Engineering Research Council (NSERC) of Canada. References Evans, E., Rogers, D., Using java applets and CORBA for multiuser distributed application. IEEE Internet computing. Farley, J., Java distributed computing. O'Reilly. Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach, 4th ed. Addison-Wesley, Reading, MA. Orfali, R., Harkey, D., Client/Server programming with Java and CORBA. Wiley, New York. Saleh, K., Java object model: elements and application. Journal of Information and Software Technology, 41 (4), 235±241. Saleh, K., Khanafer, H., Probert, R., Ural, H., 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., Issues in testing electronic commerce systems, First IBM International Workshop on Technological Challenges in Electronic Commerce, Toronto, Canada. Special issue on distributed object computing, IEEE Communications Magazine 35 (2). Kassem Saleh received a B.Sc., M.Sc. and Ph.D. from the University of Ottawa in Canada in 1985, 1986 and 1991, respectively. He worked at Bell Canada from 1985 to 1991 and Concordia University for one year before joining Kuwait University in He is currently an Associate Professor in the Department of Electrical and Computer Engineering, College of Engineering and Petroleum at Kuwait University. Dr. Saleh was placed in eighth position among the top scholars in the Field of Systems and Software Engineering in an annual assessment published by the Journal of Systems and Software in October 1997 and October He was awarded the distinguished teacher prize in 1996 both from the College of Engineering and

7 K. Saleh et al. / The Journal of Systems and Software 47 (1999) 125± Petroleum at Kuwait University. Dr. Saleh serves on the editorial advisory board of the Computer Communications journal. His current research and teaching activities are in software engineering, communications software, distributed systems and internet computing. Dr. Saleh has presented many tutorials at international conferences and universities worldwide.