DOCSLIB.ORG

An Architectural Comparison of Distributed Object Technologies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Architectural Comparison of Distributed Object Technologies An Architectural Comparison of Distributed Object Technologies by Jay Ongg ABSTRACT As developers develop larger systems, distributed object technologies came into the foreground to handle complexity. This thesis examines popular architectures of component software which can be scaled to handle large scale distributed systems. These architectures include OLE by Microsoft, CORBA by the Object Management Group, and Java Beans by Sun. Many issues need to be examined, such as what platforms will the system run on and the size of the network the system will run on. The decision of what architecture is suitable for a given complex system is crucial. This thesis provides a comparative analysis to provide a rational basis for selection. Supervisor: Nishikant Sonwalkar Title: Director, Hypermedia Teaching Facility TABLE OF CONTENTS 1. INTRODUCTION AND BACKGROUND............................................................................................................... 5 1.1 COMPONENT SOFTWARE.....................................................................................................................................5 1.2 OBJECTS...................................................................................................................................................................5 1.2.1 Encapsulation ............................................................................................................................................. 5 1.2.2 Polymorphism.............................................................................................................................................. 6 1.2.3 Inheritance................................................................................................................................................... 6 1.3 OUT-OF-PROCESS OBJECTS...................................................................................................................................7 1.3.1 Local Out-of-process Objects.................................................................................................................... 7 1.3.2 Remote Objects ............................................................................................................................................ 7 1.4 DISTRIBUTED OBJECT TECHNOLOGIES.............................................................................................................8 2. CORBA SPECIFICATION........................................................................................................................................ 9 2.1 OVERVIEW...............................................................................................................................................................9 2.2 ARCHITECTURE ...................................................................................................................................................10 2.2.1 Object Request Broker (ORB).................................................................................................................10 2.2.2 IDL ...............................................................................................................................................................10 2.2.3 Object Adapters.........................................................................................................................................11 2.2.4 Interface Repository (IR) .........................................................................................................................11 2.2.5 Implementation Repository.....................................................................................................................12 2.2.6 Dynamic Invocation Interface (DII) ......................................................................................................12 2.2.7 Dynamic Skeleton Interface (DSI) .........................................................................................................12 2.2.8 Internet Interoperability Protocol (IIOP) and the Intergalactic Object Bus................................12 2.3 CORBASERVICES AND THE OBJECT MANAGEMENT ARCHITECTURE (OMA)........................................13 2.4 CORBAFACILITIES AND CORBADOMAINS.....................................................................................................13 3. OLE..............................................................................................................................................................................14 3.1 COMPONENT OBJECT MODEL (COM) AND DISTRIBUTED COM (DCOM)...............................................14 3.1.1 Interfaces and Classes..............................................................................................................................15 3.1.2 IUnknown and its members.....................................................................................................................15 3.1.3 MIDL and RPC ..........................................................................................................................................15 3.1.4 Object Registration...................................................................................................................................16 3.1.5 Local/Remote Transparency...................................................................................................................17 3.1.6 COM Services and Features ...................................................................................................................17 3.1.7 Distributed Component Object Model (DCOM) .................................................................................17 3.2 OLE AUTOMATION.............................................................................................................................................18 3.2.1 Dispinterfaces and IDispatch .................................................................................................................18 3.2.2 Locales........................................................................................................................................................19 3.2.3 Remote Automation ..................................................................................................................................19 3.3 ACTIVEX AND THE INTERNET .........................................................................................................................19 3.3.1 Architecture and Example.......................................................................................................................20 3.3.2 ActiveX controls and the Internet..........................................................................................................20 4. JAVA SOLUTIONS..................................................................................................................................................21 4.1 APPLETS...............................................................................................................................................................21 4.1.1 Untrusted Applets .....................................................................................................................................21 4.1.2 Trusted Applets..........................................................................................................................................21 4.2 JAVA DISTRIBUTED OBJECT MODEL (RMI) ...................................................................................................22 4.2.1 Dynamic Class Loading...........................................................................................................................22 4.2.2 ByteCode Passing.....................................................................................................................................23 4.3 JAVABEANS...........................................................................................................................................................23 4.3.1 JavaBeans Features .................................................................................................................................23 2 4.3.2 Bridging......................................................................................................................................................23 4.3.3 Downloading and Packaging................................................................................................................24 5. SPECIFICATION COMPARISONS......................................................................................................................25 5.1 ARCHITECTURES.................................................................................................................................................25 5.1.1 Standard Objects.......................................................................................................................................25 5.1.2 Dynamically Bindable Objects...............................................................................................................27 5.1.3 Downloadable Objects.............................................................................................................................28 5.2 LANGUAGES AND DEVELOPMENT TOOLS.......................................................................................................29 5.2.1 CORBA Language Support.....................................................................................................................29
Load more

Recommended publications
  • System Integration in Web 2.0 Environment
    Masaryk university, Faculty of Informatics Ph.D. Thesis System Integration in Web 2.0 Environment Pavel Drášil Supervisor: doc. RNDr. Tomáš Pitner, Ph.D. January 2011 Brno, Czech Republic Except where indicated otherwise, this thesis is my own original work. Pavel Drášil Brno, January 2011 Acknowledgements There are many people who have influenced my life and the path I have chosen in it. They have all, in their own way, made this thesis and the work described herein possible. First of all, I have to thank my supervisor, assoc. prof. Tomáš Pitner. Anytime we met, I received not only a number of valuable advices, but also a great deal of enthusiasm, understanding, appreciation, support and trust. Further, I have to thank my colleague Tomáš Ludík for lots of fruitful discussions and constructive criticism during the last year. Without any doubt, this thesis would not come into existence without the love, unceasing support and patience of the people I hold deepest in my heart – my parents and my beloved girlfriend Míša. I am grateful to them more than I can express. Abstract During the last decade, Service-Oriented Architecture (SOA) concepts have matured into a prominent architectural style for enterprise application development and integration. At the same time, Web 2.0 became a predominant paradigm in the web environment. Even if the ideological, technological and business bases of the two are quite different, significant similarities can still be found. Especially in their view of services as basic building blocks and service composition as a way of creating complex applications. Inspired by this finding, this thesis aims to contribute to the state of the art in designing service-based systems by exploring the possibilities and potential of bridging the SOA and Web 2.0 worlds.
    [Show full text]
  • Lecture 38: Concurrent & Distributed Programming Message Passing
    Lecture 38: Concurrent & Distributed Programming CSC 131 Fall, 2006 Message Passing Ada Tasks • Must provide send and receive operations w/ message and receiver/sender. • Synchronous message passing • Synchronous or asynchronous? • Tasks have some features of monitors • If asynchronous then use !mailbox" to store • Exports entry names #w/ parameters$ • If synchronous then sender and receiver must • Entry names have FIFO queues !rendezvous" before either can proceed. task body Buffer is MaxBufferSize: constant INTEGER := 50; Store: array(1..MaxBufferSize) of CHARACTER; BufferStart: INTEGER := 1; Accepting an entry BufferEnd: INTEGER := 0; BufferSize: INTEGER := 0; begin loop select when BufferSize < MaxBufferSize => accept insert(ch: in CHARACTER) do Ca!er only blocked Store(BufferEnd) := ch; in accep " end insert; select BufferEnd := BufferEnd mod MaxBufferSize + 1; BufferSize := BufferSize + 1; [when <cond> =>] <select alternative> or when BufferSize > 0 => accept delete(ch: out CHARACTER) do {or [when <cond> =>] <select alternative>} ch := Store(BufferStart); end delete; [else <statements>] BufferStart := BufferStart mod MaxBufferSize + 1; BufferSize := BufferSize -1; or end select accept more (notEmpty: out BOOLEAN) do notEmpty := BufferSize > 0; end more; or terminate; end select; end loop end Buffer; task type Producer; task body Producer is Comparing Mechanisms ch: CHARACTER; begin loop TEXT_IO.GET(ch); • Shared memory concurrency Buffer.insert(ch); end loop; ' Semaphores very low level. end Producer; ' Monitors passive regions encapsulating resources to be shared #mutual exclusion$. Cooperation enforced task type Consumer; by wait and signal statements. task body Consumer is ch: CHARACTER; begin • Distributed Systems loop ' Everything active in Ada tasks #resources and Buffer.delete(ch); processes$ TEXT_IO.PUT(ch); end loop; ' Monitors and processes can easily be structured as end Consumer; Ada tasks and vice'versa.
    [Show full text]
  • Openstep and Solaris
    OpenStep and Solaris A White Paper A Sun Microsystems, Inc. Business 2550 Garcia Avenue Mountain View, CA 94043 TM U.S.A. 1994 Sun Microsystems, Inc., NeXT Computer, Inc. Sunsoft 2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A. NeXT Computer, Inc. 900 Chesapeake Drive, Redwood City, California 94063 U.S.A. NEXTSTEP Release 3 Copyright 1988-1994 NeXT Computer, Inc. All rights reserved. [6453.00] This product and related documentation are protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of NeXT, Sun and their licensors, if any. Portions of this product may be derived from the UNIX® and Berkeley 4.3 BSD systems, licensed from UNIX System Laboratories, Inc. and the University of California, respectively. Third-party font software in this product is protected by copyright and licensed from NeXT’s Font Suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS 252.227-7013 (c)(1)(ii) and FAR 52.227-19. The product described in this publication may be protected by one or more U.S. patents, foreign patents, or pending applications. TRADEMARKS Sun, Sun Microsystems, the Sun logo, SMCC, the SMCC logo, SunSoft, the SunSoft logo, Solaris, SunOS, OpenWindows, DeskSet, ONC, NFS, NetISAM, and ToolTalk are trademarks or registered trademarks of Sun Microsystems, Inc. NeXT, the NeXT logo, NEXTSTEP, the NEXTSTEP logo, OpenStep, NEXTSTEP Developer, ObjectWare, Portable Distributed Objects, and PDO are trademarks or registered trademarks of NeXT Computer, Inc.
    [Show full text]
  • Distributed Object Computing (DOC) Security: Paradigms and Strategies
    M P 9 8 B M I T R E P R O D U C T Distributed Object Computing (DOC) Security: Paradigms and Strategies November 1998 Deborah J. Bodeau Charles M. Schmidt Vipin Swarup F. Javier Thayer © 1998 The MITRE Corporation MITRE Center for Integrated Intelligence Systems Bedford, Massachusetts Table of Contents Section Page 1 Introduction 1 1.1 Object-Related Concepts and Terminology 1 1.2 Security Concerns 3 1.3 Interoperability Concerns 4 1.4 Frameworks for Understanding Distributed Object Computing and Security 5 2 Characterization and Comparison Strategies 7 2.1 Characterization Framework 7 2.2 Object-Related Concepts in Different DOC Paradigms 10 2.3 High-Level Comparison 13 3 CORBA 15 3.1 CORBA Motivation and Background 15 3.1.1 CORBA Object Model 16 3.1.2 Architectural Overview 16 3.1.3 Security Services in the Architecture 18 3.2 Technical Perspective on CORBA at the Conceptual Stratum 18 3.2.1 CORBA Object Model 20 3.3 Technical Perspective on CORBA at the Architectural Stratum 23 3.3.1 Security Domains in CORBA 23 3.3.2 The CORBA Threat-Mitigation Model 24 3.4 Characterizing CORBA-Compliant Architectures, Systems, and Products 25 3.4.1 Conceptual Stratum 25 3.4.2 Architectural Stratum 26 3.4.3 Implementation Stratum 27 4 COM, DCOM, and COM+ 28 4.1 COM Motivation and Background 28 4.1.1 Architectural Overview 29 4.1.2 Security Services in the Architecture 30 4.2 Technical Perspective on COM at the Conceptual Stratum 30 4.3 Technical Perspective on COM at the Architectural Stratum 31 4.3.1 Security Services 32 4.3.2 Processing Overview
    [Show full text]
  • Parallel Distributed Object-Oriented Framework for Domain Decomposition
    Parallel Distributed Object-Oriented Framework for Domain Decomposition S.P. Kopyssov, I.V. Krasnopyorov, A.K. Novikov, and V.N. Rytchkov1 UB RAS, Institute of Applied Mechanics [email protected] Summary. The aim of this work is to reduce the development costs of new domain decomposition methods and to develop the parallel distributed software adapted to high performance computers. A new approach to development of the domain de- composition software system is suggested; it is based on the object-oriented analysis and middleware CORBA, MPI. In this paper, the main steps of domain decom- position are determined, the object-oriented framework is described, and then it is extended for parallel distributed computing. The given examples demonstrate that the software developed in such a way provides mathematical clarity and rapid implementation of the parallel algorithms. 1 Introduction The idea of domain decomposition (DD) used not to be applied to parallel algorithms and it gave rise to substructuring (Przemieniecki [1968]), subcon- struction, macroelement, superelement, fragment, module-element, reduced element, Schwartz (Sobolev [1936]), capacity matrix and other methods. Usu- ally these methods have been applied to reduce an initial problem in the do- main with a complex boundary to the sequence of problems in the subdomains with sufficiently simple boundaries. Nowadays the parallel implementations of DD allow improving the computational performance. The most of DD software is based on one or another approach to the approximation of a differential problem, mostly on the finite element (FE) method. The complexity of FE models results in the necessity of using suit- able programming techniques such as the object-oriented (OO) analysis.
    [Show full text]
  • Common Object Request Broker Architecture (CORBA) for Embedded Specification
    Date: November 2008 Common Object Request Broker Architecture (CORBA) for embedded Specification Version 1.0 OMG Document Number: formal/2008-11-06 Standard document URL: http://www.omg.org/spec/CORBAe/1.0 Associated File(s)*: http://www.omg.org/spec/CORBAe/20080201 Source document: ptc/2008-02-03 * original zip file is ptc/2008-02-04 NOTE: This is the core CORBA/e specification. Mappings to particular programming languages, and the Common Object Services are documented in the other specifications that together comprise the complete CORBA specification. Please visit the CORBA download page at http://www.omg.org/technology/documents/ corba_spec_catalog.htm to find the complete CORBA specification set. Copyright © 1998, 1999, Alcatel Copyright © 1997, 1998, 1999 BEA Systems, Inc. Copyright © 1995, 1996 BNR Europe Ltd. Copyright © 1998, Borland International Copyright © 1998, Cooperative Research Centre for Distributed Systems Technology (DSTC Pty Ltd) Copyright © 2001, Concept Five Technologies Copyright © 1991, 1992, 1995, 1996, Digital Equipment Corporation Copyright © 2001, Eternal Systems, Inc. Copyright © 1995, 1996, 1998, Expersoft Corporation Copyright © 1996, 1997 FUJITSU LIMITED Copyright © 1996, Genesis Development Corporation Copyright © 1989- 2001, Hewlett-Packard Company Copyright © 2001, HighComm Copyright © 1998, 1999, Highlander Communications, L.C. Copyright © 1991, 1992, 1995, 1996 HyperDesk Corporation Copyright © 1998, 1999, Inprise Corporation Copyright © 1996 - 2001, International Business Machines Corporation Copyright
    [Show full text]
  • Parallel and Distributed Computing Using Pervasive Web and Object Technologies
    Syracuse University SURFACE Northeast Parallel Architecture Center College of Engineering and Computer Science 2008 Parallel and Distributed Computing using Pervasive Web and Object Technologies Geoffrey C. Fox Syracuse University, Northeast Parallel Architectures Center Wojtek Furmanski Syracuse University, Northeast Parallel Architectures Center Follow this and additional works at: https://surface.syr.edu/npac Part of the Computer Sciences Commons Recommended Citation Fox, Geoffrey C. and Furmanski, Wojtek, "Parallel and Distributed Computing using Pervasive Web and Object Technologies" (2008). Northeast Parallel Architecture Center. 95. https://surface.syr.edu/npac/95 This Article is brought to you for free and open access by the College of Engineering and Computer Science at SURFACE. It has been accepted for inclusion in Northeast Parallel Architecture Center by an authorized administrator of SURFACE. For more information, please contact [email protected]. Parallel and Distributed Computing using Pervasive Web and Object Technologies Geoffrey C. Fox, Wojtek Furmanski mailto:[email protected] , [email protected] NPAC, Syracuse University 111 College Place, Syracuse, NY 13244-4100 World Wide Web: http://www.npac.syr.edu/users/gcf/HPcc/HPcc.html Abstract We review the growing power and capability of commodity computing and communication technologies largely driven by commercial distributed information systems. These systems are built from CORBA, Microsoft’s COM, Javabeans, and less sophisticated web and networked approaches. One can abstract these to a three-tier model with largely independent clients connected to a distributed network of servers. The latter host various services including object and relational databases and, of course, parallel and sequential computing. High performance can be obtained by combining concurrency at the middle-server tier with optimized parallel back-end services.
    [Show full text]
  • Managing Complexity: Middleware Explained Andrew T
    DISTRIBUTED COMPUTING Managing Complexity: Middleware Explained Andrew T. Campbell, Geoff Coulson, and Michael E. Kounavis sk a network designer what middle- in a distributed environment can be a nightmare. ware is, and he’ll characterize it as part For instance, to provide basic communication of the application.Ask an application services, programming languages support sock- designer what it is, and she’ll say it’s ets, which are end points in two-way communica- Apart of the OS.Which one is it? tion links between two programs running on a Traditionally, most definitions seeking to char- network. Sockets require client and server to acterize middleware suggest that it is the software engage in application-level protocols to encode that facilitates remote database access and systems and decode messages. Designing such protocols transactions. More recently, the term has come is cumbersome and can be prone to error. to be associated—somewhat Middleware is basically an alternative to sock- Middleware lets limitingly—with distributed ets; it abstracts the communication interface to platforms like the Open the level of method invocations. Instead of work- you manage the Software Foundation’s Dis- ing directly with sockets, you call a method— complexity and tributed Computing Environ- rather, you have the illusion of calling a ment (DCE) and the Object method—on a local object.The arguments of the heterogeneity of Management Group’s Com- call are in fact packaged up by your middleware mon Object Request Broker and shipped off to the call’s remote target. In this distributed- Architecture (CORBA). And case, as in others, middleware provides the isolat- computing some have loosely applied it ing layer of software that shields you from the to systems as diverse as work- complexities of a heterogeneous environment.
    [Show full text]
  • The Design of the TAO Real-Time Object Request Broker 1 Introduction
    The Design of the TAO Real-Time Object Request Broker Douglas C. Schmidt, David L. Levine, and Sumedh Mungee g fschmidt,levine,sumedh @cs.wustl.edu Department of Computer Science, Washington University St. Louis, MO 63130, USA January 18, 1999 This article appeared in Computer Communications, El- systems command and control systems, multimedia systems, sivier Science, Volume 21, No 4, April, 1998. and simulations. In addition to requiring QoS guarantees, distributed appli- cations must be flexible and reusable. Flexibility is needed to Abstract respond rapidly to evolving functional and QoS requirements Many real-time application domains can benefit from flex- of distributed applications. Reusability is needed to yield sub- ible and open distributed architectures, such as those de- stantial improvements in productivity and to enhance the qual- fined by the CORBA specification. CORBA is an architec- ity, performance, reliability, and interoperability of distributed ture for distributed object computing being standardized by application software. the OMG. Although CORBA is well-suited for conventional re- The Common Object Request Broker Architecture quest/response applications, CORBA implementations are not (CORBA) [1] is an emerging standard for distributed object yet suited for real-time applications due to the lack of key qual- computing (DOC) middleware. DOC middleware resides ity of service (QoS) features and performance optimizations. between clients and servers. It simplifies application develop- This paper makes three contributions to the design of real- ment by providing a uniform view of heterogeneous network time CORBA systems. First, the paper describes the design and OS layers. of TAO, which is our high-performance, real-time CORBA- At the heart of DOC middleware are Object Request Brokers compliant implementation that runs on a range of OS plat- (ORBs), such as CORBA [1], DCOM [2], and Java RMI [3].
    [Show full text]
  • A Framework for Structured Distributed Object Computing
    A Framework for Structured Distributed Object Computing K. Mani Chandy, Joseph Kiniry, Adam Rifkin, and Daniel Zimmerman∗ [email protected] Computer Science 256-80 California Institute of Technology Pasadena, California 91125 http://www.infospheres.caltech.edu/ Abstract This paper presents a four-faceted framework for distributed applications that use worldwide net- works connecting large numbers of people, software tools, monitoring instruments, and control devices. We describe a class of applications, identify requirements for a framework that supports these applica- tions, and propose a design fulfilling those requirements. We discuss some initial experiences using the framework, and compare our design with other approaches. ∗The Caltech Infospheres Project is sponsored by the Air Force Office of Scientific Research under grant AFOSR F49620-94- 1-0244, by the CISE directorate of the National Science Foundation under Problem Solving Environments grant CCR-9527130, by the Center for Research in Parallel Computing under grant NSF CCR-9120008, by the Advanced Research Projects Agency, and by Parasoft, Inc. and Novell, Inc. This paper is partially based upon work supported under a National Science Foundation Graduate Fellowship. 1 1 Personal Command and Control Applications The global information infrastructure will soon connect large numbers of processes that manage devices and human interfaces. Interprocess communication will allow processes to respond to events on such devices as medical monitoring equipment, scientific instruments, home appliances, and security systems, and on such software as scheduling programs, document management systems, Web browsers, and complex computation engines. The contribution of this paper is a simple, generic framework for developing distributed systems for personal applications.
    [Show full text]
  • Message Passing Vs. Distributed Objects
    Message Passing vs. Distributed Objects 5/15/2009 Distributed Computing, M. L. Liu 1 Distributed Objects M. L. Liu 5/15/2009 Distributed Computing, M. L. Liu 2 Message Passing versus Distributed Objects The message-passing paradigm is a natural model for distributed computing, in the sense that it mimics interhuman communications. It is an appropriate paradigm for network services where processes interact with each other through the exchanges of messages. However, the abstraction provided by this paradigm does not meet the needs of the complexity of sophisticated network applications. 5/15/2009 Distributed Computing, M. L. Liu 3 Message Passing versus Distributed Objects –2 Message passing requires the participating processes to be tightly-coupled: throughout their interaction, the processes must be in direct communication with each other. If communication is lost between the processes (due to failures in the communication link, in the systems, or in one of the processes), the collaboration fails. The message-passing paradigm is data-oriented. Each message contains data marshalled in a mutually agreed upon format, and is interpreted as a request or response according to the protocol. The receiving of each message triggers an action in the receiving process. It is inadequate for complex applications involving a large mix of requests and responses. In such an application, the task of interpreting the messages can become overwhelming. 5/15/2009 Distributed Computing, M. L. Liu 4 The distributed object paradigm The distributed object paradigm is a paradigm that provides abstractions beyond those of the message- passing model. As its name implies, the paradigm is based on objects that exist in a distributed system.
    [Show full text]
  • Ieeecomm.Pdf
    Constructing Reliable Distributed Communication Systems with CORBA Silvano Maffeis Douglas C. Schmidt [email protected] [email protected] Olsen and Associates Department of Computer Science Zurich, Switzerland Washington University, St. Louis This paper will appear in the feature topic issue on Dis- rameter marshalling and demarshalling; and operation dis- tributed Object Computing in the IEEE Communications patching. Magazine, Vol. 14, No. 2, February 1997. Experience over the past several years [3] illustrates that CORBA is well-suited for best-effort, client-server applica- tions running over conventional local area networks (such Abstract as Ethernet and Token Ring). However, building highly Communication software and distributed services for next- available applications with CORBA is much harder. Neither generation applications must be reliable, ef®cient, ¯ex- the CORBA standard nor conventional implementations of ible, and reusable. These requirements motivate the CORBA directly address complex problems related to dis- use of the Common Object Request Broker Architecture tributed computing, such as real-time quality of service [4] (CORBA). However, building highly available applications or high-speed performance [5], group communication [6], with CORBA is hard. Neither the CORBA standard nor partial failures, [7] and causal ordering of events [8]. conventional implementations of CORBA directly address This paper makes three contributions to the study of re- complex problems related to distributed computing, such as liable distributed object computing systems with CORBA. real-time or high-speed quality of service, partial failures, First, we examine the question of whether reliable applica- group communication, and causal ordering of events. This tions can (or should) be implemented with CORBA today.
    [Show full text]