DOCSLIB.ORG

The Common Object Request Broker: Architecture and Specification

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Common Object Request Broker: Architecture and Specification The Common Object Request Broker: Architecture and Specification Digital Equipment Corporation Hewlett-Packard Company HyperDesk Corporation NCR Corporation Object Design, Inc. SunSoft, Inc. OMG Document Number 93.xx.yy Revision 1.2 Draft 29 December 1993 Copyright 1991, 1992 by Digital Equipment Corporation Copyright 1989, 1990, 1991, 1992 by Hewlett-Packard Corporation Copyright 1991, 1992 by HyperDesk Corporation Copyright 1991, 1992 by NCR Corporation Copyright 1991,1992 by Object Design, Inc. Copyright 1991, 1992 by Sun Microsystems, Inc. Sun Microsystems, Inc., Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Digital Equipment Corporation, and Object Design, Inc. hereby grant to the Object Management Group, Inc. a non-exclusive, royalty- free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute cop- ies of the modified version. Each of the copyright holders listed above agrees that not person shall be deemed to have infringed any copyright, patent or any other proprietary right of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. NOTICE The information contained in this document is subject to change without notice. The material in this document details an Object Management Group specification in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this spec- ification in any companies' products. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE OBJECT MANAGEMENT GROUP, DIGITAL EQUIPMENT CORPORATION, HEWLETT-PACKARD COMPANY, HYPERDESK CORPORATION, NCR CORPORATION, OBJECT DESIGN, INC., SUN MICROSYSTEMS, INC., AND X/OPEN CO. LTD., MAKE NO WARRANTY OF ANY KIND WITH REGARDS TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The Object Management Group, Inc., Digital Equipment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Object Design, Inc., Sun Microsystems, Inc., and X/Open Co. Ltd. shall not be liable for errors contained herein or for inci- dental or consequential damages in connection with the furnishing, performance or use of this material. The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its des- ignees) is and shall tat all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these mate- rials. This document contains information which is protected by copyright. All Rights Reserved. No part of this work cov- ered by copyright hereon may be reproduced or used in any form or by any means--graphic, electronic or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner. RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013. Hewlett-Packard Company is a trademark of Hewlett-Packard Company HyperDesk is a trademark of HyperDesk Corporation SunSoft is a trademark of Sun Microsystems, Inc., licensed to SunSoft, Inc. X/Open and the "X" symbol are trademarks of X/Open Company Limited. Preface on X/Open X/Open is an independent, worldwide, open systems organization supported by most of the world's largest information system suppliers, user organizations and software companies. Its mission is to bring to users greater value from computing, through the practical implementation of open systems. X/Open's strategy for achieving this goal is to combine existing and emerging standards into a com- prehensive, integrated, high value and usable systems environment called the Common Applications Environment (CAE). The components of the CAE are defined in X/Open CAE specifications. These contain, among other things, an evolving portfolio of practical application programming interfaces (API's), which signifi- cantly enhance portability of application programs at the source code level, and definitions of, and references to, protocols and protocol profiles, which significantly enhance the interoperability of applications. The X/Open CAE Specifications are supported further by an extensive set of conformance tests and a distinct X/Open trademark - the XPG Brand - that is licensed by X/Open and may be carried only on products that comply with the CAE specifications. This Document This document is a joint publication of X/Open and the Object Management Group and is endorsed by both organizations. In terms of the X/Open family of publications, it has the stand- ing as an X/Open Preliminary Specification of the Object Request Broker component of responses. The Object Request Broker provides interoperability between applications on differ- ent machines in distributed environments. "X/Open" and the "X" symbol are Trademarks of X/Open Company Limited. Table of Contents 1 Overview 15 1.1 Overview 15 1.2 Typographical Conventions 17 2 The Object Model 19 2.1 Overview 19 2.2 Object Semantics 20 2.2.1 Objects 21 2.2.2 Requests 21 2.2.3 Object Creation and Destruction 22 2.2.4 Types 22 2.2.5 Interfaces 24 2.2.6 Operations 24 2.2.7 Attributes 26 2.3 Object Implementation 26 2.3.1 The Execution Model: Performing Services 26 2.3.2 The Construction Model 27 3 The Common Object Request Broker Architecture 29 3.1 The Structure of an Object Request Broker 30 3.1.1 Object Request Broker 34 3.1.2 Clients 35 3.1.3 Object Implementations 35 THE COMMON OBJECT REQUEST BROKER: ARCHITECTURE AND SPECIFICATION v Contents 3.1.4 Object References 36 3.1.5 IDL Interface Definition Language 36 3.1.6 Programming Language Mapping 36 3.1.7 Client Stubs 37 3.1.8 Dynamic Invocation Interface 37 3.1.9 Implementation Skeleton 37 3.1.10 Object Adapters 38 3.1.11 ORB Interface 38 3.1.12 Interface Repository 38 3.1.13 Implementation Repository 39 3.2 Some Example ORBs 39 3.2.1 Client- and Implementation-resident ORB 39 3.2.2 Server-based ORB 39 3.2.3 System-based ORB 39 3.2.4 Library-based ORB 40 3.3 The Structure of a Client 40 3.4 The Structure of an Object Implementation 42 3.5 The Structure of an Object Adapter 43 3.6 Some Example Object Adapters 45 3.6.1 Basic Object Adapter 45 3.6.2 Library Object Adapter 45 3.6.3 Object-Oriented Database Adapter 45 3.7 The Integration of Foreign Object Systems 46 4 IDL Syntax and Semantics 47 4.1 Lexical Conventions 49 4.1.1 Tokens 52 4.1.2 Comments 52 4.1.3 Identifiers 52 4.1.4 Keywords 53 4.1.5 Literals 54 4.2 Preprocessing 56 4.3 IDL Grammar 56 4.4 IDL Specification 60 4.4.1 Module Declaration 61 4.4.2 Interface Declaration 61 4.5 Inheritance 63 4.6 Constant Declaration 65 4.6.1 Syntax 65 4.6.2 Semantics 66 4.7 Type Declaration 68 4.7.1 Basic Types 69 4.7.2 Constructed Types 70 4.7.3 Template Types 73 4.7.4 Complex Declarator 74 4.8 Exception Declaration 75 4.9 Operation Declaration 75 4.9.1 Operation Attribute 76 vi THE COMMON OBJECT REQUEST BROKER: ARCHITECTURE AND SPECIFICATION Contents 4.9.2 Parameter Declarations 76 4.9.3 Raises Expressions 77 4.9.4 Context Expressions 77 4.10 Attribute Declaration 78 4.11 CORBA Module 79 4.12 Names and Scoping 79 4.13 Differences from C++ 82 4.14 Standard Exceptions 82 5 C Language Stub Mapping 85 5.1 Requirements for a Language Mapping 85 5.1.1 Basic Data Types 86 5.1.2 Constructed Data Types 86 5.1.3 Constants 86 5.1.4 Objects 86 5.1.5 Invocation of Operations 87 5.1.6 Exceptions 87 5.1.7 Attributes 88 5.1.8 ORB Interfaces 88 5.1.9 Language Stub Mapping 89 5.2 Scoped Names 89 5.3 Mapping for Interfaces 90 5.4 Inheritance and Operation Names 91 5.5 Mapping for Attributes 92 5.6 Mapping for Constants 93 5.7 Mapping for Basic Data Types 93 5.8 Mapping for Structure Types 94 5.9 Mapping for Union Types 94 5.10 Mapping for Sequence Types 95 5.11 Mapping for Strings 97 5.12 Mapping for Arrays 99 5.13 Mapping for Exception Types 99 5.14 Implicit Arguments to Operations 99 5.15 Interpretation of Functions with Empty Argument Lists 100 5.16 Argument Passing Considerations 100 5.17 Return Result Passing Considerations 101 5.18 Summary of Argument/Result Passing 102 5.19 Handling Exceptions 104 5.20 Method Routine Signatures 107 5.21 Include Files 107 5.22 Pseudo-objects 107 THE COMMON OBJECT REQUEST BROKER: ARCHITECTURE AND SPECIFICATION vii Contents 6 Dynamic Invocation Interface 109 6.1 Overview 109 6.1.1 Common Data Structures 110 6.1.2 Memory Usage 112 6.1.3 Return Statuses and Exceptions 112 6.2 Request Routines 112 6.2.1 create_request 113 6.2.2 add_arg 115 6.2.3 invoke 115 6.2.4 delete 116 6.3 Deferred Synchronous Routines 116 6.3.1 send 116 6.3.2 send_multiple_requests 117 6.3.3 get_response 117 6.3.4 get_next_response 118 6.4 List Routines 118 6.4.1 create_list 119 6.4.2 add_item 119 6.4.3 free 120 6.4.4 free_memory 120 6.4.5 get_count 120 6.4.6 create_operation_list 120 6.5 Context Objects 121 6.6 Context Object Routines 122 6.6.1 get_default_context 123 6.6.2 set_one_value 124 6.6.3 set_values 124 6.6.4 get_values 124 6.6.5 delete_values 125 6.6.6 create_child 125 6.6.7 delete 125 6.7 Native Data Manipulation 126 7 The Interface Repository 127 7.1 Overview 127 7.2 Scope of an Interface Repository 128 7.3 Implementation Dependencies 129 7.4 Basics of the Interface Repository
Load more

Recommended publications
  • Distributed Objects in C
    Rochester Institute of Technology RIT Scholar Works Theses 2006 Distributed Objects in C# Xiaoyun Xie Follow this and additional works at: https://scholarworks.rit.edu/theses Recommended Citation Xie, Xiaoyun, "Distributed Objects in C#" (2006). Thesis. Rochester Institute of Technology. Accessed from This Master's Project is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Rochester Institute of Technology Department of Computer Science Master of Science Project Distributed Objects System in C# Submitted By: Xie, Xiaoyun (Sherry) Date: February 2004 Chairman: Dr. Axel T. Schreiner Reader: Dr. Hans-Peter Bischof Observer: Dr. James Heliotis 2 ABSTRACT Today more and more programs run over a collection of autonomous computers linked by a network and are designed to produce an integrated computing facility. Java Distributed Objects (JDO) proposed by Dr. Axel T. Schreiner [1] builds an infrastructure which allows distributed program components to communicate over a network in a transparent, reliable, efficient, and generic way. JDO was originally intended as a teaching device to assess design parameters for distributed objects. This project focuses on porting JDO, which is implemented in Java on Sun’s JDK, to C# on Microsoft’s .NET. On one hand, it builds an infrastructure in C# that simplifies the construction of distributed programs by hiding the distributed nature of remote objects. On the other hand, it generates insights into the differences between two platforms, namely, Java on Sun and C# on .NET, in the distributed objects area.
    [Show full text]
  • Reflective Remote Method Invocation
    Loyola University Chicago Loyola eCommons Computer Science: Faculty Publications and Other Works Faculty Publications 1998 Reflective Remote Method Invocation George K. Thiruvathukal Loyola University Chicago, [email protected] Lovely S. Thomas Andy T. Korczynski Follow this and additional works at: https://ecommons.luc.edu/cs_facpubs Part of the Programming Languages and Compilers Commons Recommended Citation G. Thiruvathukal, L. Thomas, and A. Korczynski, “Reflective Remote Method Invocation,” in ACM Java Grande, 1998. This Conference Proceeding is brought to you for free and open access by the Faculty Publications at Loyola eCommons. It has been accepted for inclusion in Computer Science: Faculty Publications and Other Works by an authorized administrator of Loyola eCommons. For more information, please contact [email protected]. This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. Copyright © 1998 George K. Thiruvathukal, Lovely S. Thomas, and A. Korczynski Reflective Remote Method Invocation G. K. Thiruvathukal1 Tools of Computing LLC and Argonne National Laboratory Chicago, Illinois, U.S.A. L. S. Thomas2 Illinois Institute of Technology, Chicago, Illinois, U.S.A. A. T. Korczynski3 Illinois Institute of Technology, Chicago, Illinois, U.S.A. Abstract Remote Method Invocation (RMI) is available in the current Java language design and implementation, providing the much-needed capability of allowing objects running in different Java processes to collaborate using a variation on the popular Remote Procedure Call (RPC). Although RMI provides features which are desirable for high-performance distributed computing, its design and implementation are deficient in key areas of importance to the high-performance computing community in general.
    [Show full text]
  • Websphere Product Family: Overview and Architecture
    Front cover WebSphere Product Family Overview and Architecture Discover the WebSphere family Take an in-depth look at key products Compare capabilities Carla Sadtler Gennaro Cuomo John Ganci Marc Haberkorn Carol Jones Peter Kovari Kevin Griffith Dildar Marhas Rob Will ibm.com/redbooks International Technical Support Organization WebSphere Product Family Overview and Architecture February 2005 SG24-6963-02 Note: Before using this information and the product it supports, read the information in “Notices” on page xv. Third Edition (February 2005) This edition applies to the WebSphere family. © Copyright International Business Machines Corporation 2004, 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . xv Trademarks . xvi Preface . xvii The team that wrote this redbook. xvii Become a published author . xix Comments welcome. xix Summary of changes . xxi February 2005, Third Edition . xxi Chapter 1. IBM WebSphere product overview . xxiii 1.1 WebSphere overview . xxiv 1.2 WebSphere family . xxv 1.3 IBM WebSphere Application Servers . xxvi 1.3.1 WebSphere Application Server V6 for distributed platforms . xxviii 1.3.2 WebSphere Application Server V5.1. xxxi 1.3.3 WebSphere Extended Deployment V5.1 . xxxiii 1.4 IBM software development platform . xxxv 1.4.1 Application development for WebSphere Application Server V6 . xxxvi 1.4.2 WebSphere Studio and Rational Developer . .xxxvii 1.5 IBM WebSphere Business Integration products . .xliii 1.5.1 Integration servers . xlv 1.5.2 Product overview. xlvi 1.5.3 WebSphere Business Integration Server Foundation . xlvi 1.5.4 WebSphere Business Integration Server .
    [Show full text]
  • Remote Procedure Call (RPC)
    Remote Procedure Call (RPC) RPC – RMI - Web Services 1 Complexity of the distributed applications . The programming of distributed applications is difficult. In addition to the usual tasks, programmers who build clients and servers must deal with the complex issues of communication. Although many of the needed functions are supplied by a standard API such as the socket interface, the socket calls require the programmer to specify many low level details as names ,addresses,protocols and ports. Moreover, asinchronous communications models are complex to implement. Distributed implementations tend to use the same standard API (e.g.,the socket interface). As a consequence most of the detailed code found in one program is replicated in others RPC – RMI - Web Services 2 . For example, all client programs that use a connection oriented transport must create a socket, specify the server’s endpoint address, open a connection to the server, send requests,receive responses and close the connection when interaction is complete. Tools (software that generates all or part of a computer program) have been created to construct clients and servers. Tools cannot eliminate all programming: a programmer must supply the code that perform the computation for the particular service. However, a tool can handle the communication details. As a result the code contains fever bugs. RPC – RMI - Web Services 3 . RPC = Remote Procedure Call . The basic model has been proposed by Birrell e Nelson in 1984. The essence of this technique is to allow programs on different machines to interact using simple procedure call/return semantics, just as if the two programs were in the same computer .
    [Show full text]
  • A Comparative Evaluation of .Net Remoting and JAVA RMI Taneem Ibrahim University of Arkansas, Fayetteville
    Inquiry: The University of Arkansas Undergraduate Research Journal Volume 5 Article 12 Fall 2004 A Comparative Evaluation of .net Remoting and JAVA RMI Taneem Ibrahim University of Arkansas, Fayetteville Follow this and additional works at: http://scholarworks.uark.edu/inquiry Part of the Computer and Systems Architecture Commons Recommended Citation Ibrahim, Taneem (2004) "A Comparative Evaluation of .net Remoting and JAVA RMI," Inquiry: The University of Arkansas Undergraduate Research Journal: Vol. 5 , Article 12. Available at: http://scholarworks.uark.edu/inquiry/vol5/iss1/12 This Article is brought to you for free and open access by ScholarWorks@UARK. It has been accepted for inclusion in Inquiry: The nivU ersity of Arkansas Undergraduate Research Journal by an authorized editor of ScholarWorks@UARK. For more information, please contact [email protected], [email protected]. Ibrahim: A Comparative Evaluation of .net Remoting and JAVA RMI 86 INQUIRY Volume 5 2004 A COMPARATIVE EVALUATION OF .NET REMOTING ANDJAVARMI By: Taneem Ibrahim Department of Computer Science and Computer Engineering Faculty Mentor: Dr. Amy Apon Department of Computer Science and Computer Engineering Abstract: Introduction: Distributed application technologies such as A distributed system is a collection of loosely coupled Micrososoft.NEJRemoting, and Java Remote Method Invocation processors interconnected by a communication network [8]. (RMI) have evolved over many years to keep up with the From tbe point view of a specific processor in a distributed constantly increasing requirements of the enterprise. In the system, the rest of the processors and their respective resources broadest sense, a distributed application is one in which the are remote, whereas its own resources are local.
    [Show full text]
  • Distributed Objects
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by UCL Discovery Distributed Objects Wolfgang Emmerich Neil Roodyn Dept. of Computer Science Cognitech Ltd University College London City Cloisters, 188-194 Old Street London WC1E 6BT,UK London EC1V 9FR, UK [email protected] [email protected] ABSTRACT be addressed. In addition, any distributed application must This tutorial motivates the need for, and discusses the prin- be tolerant of failures, such as temporarily unreachable com- ciples of object-oriented distribution middleware. We will ponents or network time-outs. Dealing with these issues at give an overview how these principles are supported by the the network operating system layer is overly complicated for major incarnations of object-oriented middleware, the Ob- an application engineer. ject Management Group’s Common Object Request Broker Distribution middleware is layered between network operat- Architecture (CORBA), Microsoft’s Distributed Component ing systems and distributed applications in order to bridge Object Model (DCOM) and Java’s Remote Method Invoca- this gap. Middleware provides the application designer with tion (RMI). We will discuss common design problems that a higher-level of abstraction. Middleware systems imple- occur when building applications using distributed objects ment this higher level of abstraction based on primitives that and present techniques for their solution. are provided by network operating systems. While doing so 1 INTRODUCTION they hide the complexity of using a network operating sys- In a number of domains, such as the financial and telecom- tem from application designers. The idea of middleware is munications sector, applications have to be adapted to evolv- not new.
    [Show full text]
  • Distributed Objects
    Introduction to Distributed Objects The idea of distributed objects is an extension of the concept of remote procedure calls. In a remote procedure call system (Sun RPC, DCE RPC, Java RMI), code is executed remotely via a remote procedure call. The unit of distribution is the procedure / function /method (used as synonyms). So the client has to import a client stub (either manually as in RPC or automatically as in RMI) to allow it to connect to the server offering the remote procedure. Object as Distribution Unit In a system for distributed objects, the unit of distribution is the object. That is, a client imports a ”something” (in Java’s JINI system, it’s called a proxy) which allows the client access to the remote object as if it were part of the original client program (as with RPC and RMI, sort of transparently). A client actually imports a Java class and this becomes part of the set of classes available on the client machine. So, for example, the client can define subclasses of this imported class, overload methods, etc. In addition, distributed object systems provide additional services, like a discovery service that allows clients to locate the objects they need, security services, reliability services, etc. Distributed object technologies: 1. DCOM (Distributed Common Object Model), developed by Microsoft, but also available on other platforms. Built on top of DCE’s RPC, interacts with COM. 2. CORBA (Common Object Request Broker Architecture), defined by the Object Management Group, an industry consortium. CORBA is available for most major operating systems 3. JINI (“Genie,” JINI is not initials — a joke; JINI actually doesn’t stand for anything.) JINI is developed on top of Java.
    [Show full text]
  • Distributed Object Based Systems
    Distributed Systems Distributed Object-Based Systems Björn Franke University of Edinburgh, 2015 OVERVIEW • Basic Concepts • Middleware Technologies • CORBA • DCOM • .NET Remote Procedure Calls/Windows Communication Foundation • Google gRPC BASIC CONCEPTS REMOTE PROCEDURE CALLS (RPC) BASIC CONCEPTS REMOTE PROCEDURE CALLS (RPC) BASIC CONCEPTS MARSHALLING/UNMARSHALLING MIDDLEWARE TECHNOLOGIES HIGH-LEVEL VIEW MIDDLEWARE TECHNOLOGIES SLIGHTLY MORE DETAIL • High-level abstractions & API • Heterogeneity Hidden • Transparent Distribution • General purpose services e.g. directory/naming CORBA COMMON OBJECT REQUEST BROKER ARCHITECTURE • Industry-defined standard for distributed objects • Enables collaboration between systems on different operating systems, programming languages, and computing hardware • Interface definition language (IDL) to specify object interfaces. CORBA then specifies a mapping from IDL to a specific implementation language. • Central: Object request brokers (ORBs) • Application initialises ORB, and accesses an internal Object Adapter, which maintains things like reference counting, object (and reference) instantiation policies, and object lifetime policies. • Object Adapter is used to register instances of the generated code classes (result of compiling the user IDL code, which translates interface definitions into an OS- and language-specific class base for use by the user application). CORBA GLOBAL ARCHITECTURE • The Object Request Broker (ORB) forms the core of any CORBA distributed system. • Horizontal facilities consist
    [Show full text]
  • Distributed Computing Paradigms Distributed Application Paradigms
    Distributed Computing Paradigms Distributed Application Paradigms level of abstraction high object space network services, object request broker, mobile agent remote procedure call, remote method invocation client-server message passing low The Message Passing Paradigm Message passing is the most fundamental paradigm for distributed applications. A process sends a message representing a request. The message is delivered to a receiver, which processes the request, and sends a message in response. In turn, the reply may trigger a further request, which leads to a subsequent reply, and so forth. Process A Process B a message Me ssage passing The Message Passing Paradigm The basic operations required to support the basic message passing paradigm are send, and receive. For connection-oriented communication, the operations connect and disconnect are also required. With the abstraction provided by this model, the interconnected processes perform input and output to each other, in a manner similar to file I/O. The I/O operations encapsulate the detail of network communication at the operating-system level. The socket application programming interface is based on this paradigm. http://java.sun.com/products/jdk/1.2/docs/api/index.html http://www.sockets.com/ The Client-Server Paradigm Perhaps the best known paradigm for network applications, the client-server model assigns asymmetric roles to two collaborating processes. One process, the server, plays the role of a service provider which waits passively for the arrival of requests. The other, the client, issues specific requests to the server and awaits its response. service request a client process a server process Server host a service Client host ..
    [Show full text]
  • Distributed Computing Paradigms
    Distributed Computing Paradigms Mei-Ling Liu Distributed Computing Paradigms, 5/8/2007 M. Liu 1 Paradigms for Distributed Applications Paradigm means “a pattern, example, or model.” In the study of any subject of great complexity, it is useful to identify the basic patterns or models, and classify the detail according to these models. This paper aims to present a classification of the paradigms for distributed applications. Characteristics that distinguish distributed applications from conventional applications which run on a single machine. These characteristics are: w Interprocess communication: A distributed application require the participation of two or more independent entities (processes). To do so, the processes must have the ability to exchange data among themselves. w Event synchronization: In a distributed application, the sending and receiving of data among the participants of a distributed application must be synchronized. Distributed Computing Paradigms, 5/8/2007 M. Liu 2 Abstractions Arguably the most fundamental concept in computer science, abstraction is the idea of detail hiding. To quote David J. Barnes1: We often use abstraction when it is not necessary to know the exact details of how something works or is represented, because we can still make use of it in its simplified form. Getting involved with the detail often tends to obscure what we are trying to understand, rather than illuminate it … Abstraction plays a very important role in programming because we often want to model, in software, simplified versions of things that exist in the real world … without having to build the real things. In software engineering, abstraction is realized with the provision of tools or facilities which allow software to be built without the developer having to be cognizant of some of the underlying complexities.
    [Show full text]
  • Distributed Object Systems
    Distributed Systems Distributed Object-Based Systems Björn Franke University of Edinburgh, 2016 OVERVIEW • Basic Concepts • Middleware Technologies • Apache Ignite (see coursework lecture) • CORBA • DCOM • .NET Remote Procedure Calls/Windows Communication Foundation • Google gRPC BASIC CONCEPTS REMOTE PROCEDURE CALLS (RPC) BASIC CONCEPTS REMOTE PROCEDURE CALLS (RPC) BASIC CONCEPTS MARSHALLING/UNMARSHALLING MIDDLEWARE TECHNOLOGIES HIGH-LEVEL VIEW MIDDLEWARE TECHNOLOGIES SLIGHTLY MORE DETAIL • High-level abstractions & API • Heterogeneity Hidden • Transparent Distribution • General purpose services e.g. directory/naming CORBA COMMON OBJECT REQUEST BROKER ARCHITECTURE • Industry-defined standard for distributed objects • Enables collaboration between systems on different operating systems, programming languages, and computing hardware • Interface definition language (IDL) to specify object interfaces. CORBA then specifies a mapping from IDL to a specific implementation language. • Central: Object request brokers (ORBs) • Application initialises ORB, and accesses an internal Object Adapter, which maintains things like reference counting, object (and reference) instantiation policies, and object lifetime policies. • Object Adapter is used to register instances of the generated code classes (result of compiling the user IDL code, which translates interface definitions into an OS- and language-specific class base for use by the user application). CORBA GLOBAL ARCHITECTURE • The Object Request Broker (ORB) forms the core of any CORBA distributed
    [Show full text]
  • Portable Serialization of CORBA Objects: a Reflective Approach Marc-Olivier Killijian Juan-Carlos Ruiz Jean-Charles Fabre LAAS-CNRS LAAS-CNRS LAAS-CNRS 7, Av
    Portable Serialization of CORBA Objects: a Reflective Approach Marc-Olivier Killijian Juan-Carlos Ruiz Jean-Charles Fabre LAAS-CNRS LAAS-CNRS LAAS-CNRS 7, Av. du Colonel Roche 7, Av. du Colonel Roche 7, Av. du Colonel Roche 31077 Toulouse Cedex 4 (France) 31077 Toulouse Cedex 4 (France) 31077 Toulouse Cedex 4 (France) +33.5.61.33.62.41 +33.5.61.33.69.09 +33.5.61.33.62.36 [email protected] [email protected] [email protected] ABSTRACT resulting from different programming languages. We use in this paper the terms portable and language (and platform) The objective of this work is to define, implement and independent interchangeably. illustrate a portable serialization technique for CORBA objects. We propose an approach based on reflection: through Serialization in a homogeneous environment has been studied open compilers facilities the internal state of CORBA objects quite extensively, e.g. in [1] [2]. This is not the case of is obtained and transformed into a language independent serialization in heterogeneous environments where works like format using CORBA mechanisms. This state can be restored [3] [4] focus on platform interoperability but not on language and used by objects developed using different languages and portability. Our objective in this work is to provide facilities running on different software platforms. A tool was developed to serialize and de-serialize CORBA objects in a portable and applied to a Chat application as a case study. The format. We introduce an abstract model of object state so that a proposed technique is used to exchange state information serialized state is interoperable and portable.
    [Show full text]