Paradigms by sdsdfqw21


   We Know Principles, What Now?
•  We studied principles of distributed systems:
   –  Communication;
   –  Processes;
   –  Naming;
   –  Synchronization;
   –  Consistency & replication;
   –  Fault tolerance;
   –  Security;
•  Now we concentrate on extended examples (paradigms)
   –  Easier to compare different implementations of these paradigms
   –  Better understanding of principles
   –  Useful for revision
                Next Few Lectures
•  Distributed Object-Based systems
  –  Java RMI
  –  CORBA
•  Distributed File Systems
  –  NFS
  –  Coda
•  Distributed Coordination Systems
  –  Jini
  Distributed Object-Based Systems
•  Java RMI
  –  Pure Java solution
•  Common Object Request Broker Architecture
  –  Interoperability

•  Distributed Component Object Model (DCOM)
   from Microsoft
  –  Windows-only solution
           Mission of CORBA

What happens if many long-established companies
   wish to develop applications that interface with
 their current software written in languages such as
                 C, COBOL and C++

          Introduction to CORBA
•  The Object Management Group (OMG) was
   formed in 1989. About 800 members. Its aims
  –  to make better use of distributed systems
  –  to use object-oriented programming
  –  to allow objects in different programming languages to
     communicate with one another
•  The object request broker (ORB) enables clients to
   invoke methods in a remote object
•  CORBA is a specification of an architecture
   supporting this (rather than an implementation).
             What is CORBA
CORBA is not an implementation medium (as RMI)

 It is a specification of the services provided by a
     system which can support distributed objects
 programmed in a variety of languages on a variety
                 of operating systems.
      Achieves consensus on interoperability.
 This enables it to be used for legacy applications.
           The Distributed Object


Common organization of a remote object with client-side “proxy”.
     •  The “proxy” can be thought of as the “client stub”.
   •  The “skeleton” can be thought of as the “server stub”.
            Overview of CORBA

•  ORB: the runtime system responsible for
   communication between objects and their clients
•  CORBA standard facilities:
  –  Horizontal facilities (e.g., user interfaces, information
     management, task management…)
  –  Vertical facilities (e.g., electronic commerce, banking,
                  CORBA RMI
•  The term CORBA object is used to refer to remote
•  Objects and services are specified in the CORBA
   Interface Definition Language (IDL)
  –  It is not possible to describe semantics in CORBA IDL;
•  Clients are not necessarily objects;
   (A CORBA object can be implemented by a
   language without classes. The class concept does
   not exist in CORBA).
            CORBA Components
The main components of CORBA are:
•  An Interface Definition Language (IDL)
  –  and its mapping onto the implementation language (C, C
     ++, Java, Smalltalk, Ada, COBOL)

•  The architecture
  –  The object model offered by CORBA
Role of Interface Definition Language

  Client Side


                         I D L
                                  I D L

                    I D L
                                            I D L

    COBO                                                                              Ada

       I D L
                                                     I D L


               I D L
                                                     I D L


                    I D L
                                            I D L

                         I D L
                                  I D L




General Organization of a CORBA System

•  ORB offers:                       •  Interfaces:
   –  Basic communication               –  Static (described in IDL)
   –  Object references                 –  Run-time creation (Dynamic
   –  Initial finding the services         Invocation Interface)
•  Originally, very simple: a client invokes a method
   and waits for an answer
•  What to do in the presence of failures?
  –  Synchronous requests (at-most-once semantics)
  –  One-way requests
     •  Invoke a remote method and continue. No reply is expected
        from the method.
  –  Deferred synchronous requests
     •  Check after a while
     Invocation Models Summary
Request type     Failure semantics              Description
Synchronous    At-most-once           Caller blocks until a response is
                                      returned or an exception is
One-way        Best effort delivery   Caller continues immediately
                                      without waiting for any response
                                      from the server

Deferred       At-most-once           Caller continues immediately
synchronous                           and can later block until
                                      response is delivered
Event and Notification Services (1)

 The logical organization of suppliers and consumers
   of events, following the push-style model.
Event and Notification Services (2)
         Persistent Communication
  RMI and Event&Notification services are transient.
•  CORBA messaging service: Object-oriented
   approach to communication
•  All communication takes place by invoking an
  –  May not be possible to get an immediate reply
  –  Callback model: A client features two interfaces
  –  Polling model: A client is offered a collection of
     operations to poll its ORB for incoming results
•  Messages sent are stored by he underlying system in
   case the client or server is not yet running
       Callback Messaging Model

A client features two interfaces
   •  Specification of the method that a client can call
   •  Callback interface
  Polling Messaging Model

Client checks if a reply has arrived
 Communications and Interoperability
•  Interoperability is achieved by the introduction of a
   standard inter-ORB protocol (General Inter-ORB
   Protocol GIOP) which
  –  Defines an external data representation, called CDR
  –  Specifies formats for the messages in a request-reply
     •  including messages for enquiring about the location of an
        object, for canceling requests and for reporting errors.
•  The Internet Inter-ORB protocol (IIOP) defines a
   standard form for remote object references.
  –  IIOP is GIOP implemented in TCP/IP
•  Two types of processes: clients and servers
  –  Make clients as simple as possible
     •  Easy for applications developers to make use of existing
        services as implemented on the servers
     •  The IDL specification is compiled into a proxy
     •  Proxy connects a client application to the underlying ORB
  –  On the server side, the Portable Object Adapter (POA)
     makes code appear as CORBA objects to clients
     •  Creates remote object references for CORBA objects;
     •  Activates objects;
     •  Implements a specific activation policy (e.g., thread-per-
        request, thread-per-connection, thread-per-object policy,…);
     •  Methods are implemented by means of servants.
  Compile-time vs. Run-time Objects
•  Compile-time distributed objects generally assume the use
   of a particular programming language (Java or C++).
•  This is often seen as a drawback (inflexible).

•  Run-time distributed objects provide object adaptors to
   objects, designed to remove the compile-time
   programming language restriction.
•  Using object adaptors allows an object implementation to
   be developed in any way – as long as the resulting
   implementation “appears” like an object, then things are
   assumed to be OK.
     Persistent vs. Transient Objects
•  A “persistent” distributed object continues to exist even
   after it no longer exists in the address space of the server.
•  It is stored (perhaps on secondary storage) and can be re-
   instantiated at a later date by a newer server process (i.e.
   by a newer object).

•  A “transient” distributed object does not persist.
•  As soon as the server exits, the transient object is

Which one is better is the subject of much controversy …
     Static vs. Dynamic Invocation
Predefined interface definitions support static
-  all interfaces are known up-front.
-  a change to the interface requires all applications
   (i.e. clients) to be recompiled.

Dynamic invocation “composes” a method at run-
-  interface can “come and go” as required.
-  interfaces can be changed without forcing a
   recompile of client applications.           25
     Portable Object Adaptor

Mapping of CORBA object identifiers to servants.
a)  The POA supports multiple servants.
b)  The POA supports a single servant.
                    Naming (1)
•  CORBA objects are references by means of
   language-independent object references
   (Interoperable Object Reference, IOR)
•  CORBA naming service is a binder that provides
   methods including
  –  Rebind for servers to register the remote object
     references of CORBA objects by name
     (e.g. rebind(path, Object))
  –  Resolve for clients to look them up by name.
     (e.g. Object = resolve(path))
                            Naming (2)
•  The names are structured in a hierarchy,
   –  A path is an array of NameComponent (a struct with a name in it)
   –  The path starts from an initial context provided by CORBA
   –  Naming context is an object that stores a table mapping name
      components to object references. (Thus, a naming context is the
      same as a directory node)
      •  Integration namespaces is straightforward. Naming contexts are regular
         objects, hence, a foreign name space can be registered under a specific name
         in the naming graph. Resolving the name will return an IOR referring to the
         foreign naming context.
•  The name service is present in all CORBA installations.
   (It’s role is like the Java RMI registry)
         Caching and Replication
•  No support for caching and replication in CORBA
   (except for fault tolerance)
•  Ad-hoc approaches
  –  Using interceptors: mechanisms by which an invocation
     can be intercepted on its way from the client to server
     and adapted as necessary before letting it continue.
  –  Request-level interceptor—placed between a client’s
     proxy and the ORB;
  –  Message-level interceptor—placed between an ORB
     and the underlying network.

Interceptors may be used to replicate objects in a
                 transparent way
                  Fault Tolerance
•  Replicate objects into groups
  –  One or more identical copies of the same object
  –  An object group can be references as if it were a single
  –  Replication is transparent to clients.
•  Whenever a client passes an object reference to its
   ORB, that ORB attempts to bind one of the replicas.
•  If binding to one of the replicas fails, the client ORB
   continue by attempting to bind another replica.
  Example Fault Tolerant Architecture

•  Reliable total-oriented multicasting is assumed
•  Active replication in use
•  Interceptors again
•  Original version had no security
•  CORBA 2.4 takes over 400 pages to specify security
•  Implementation should be transparent to clients
•  Clients might have specific security requirements
•  Security policy
  –  When security to be used
     •  Binding time, invocation time, both,…
  –  Where should be used
     •  Application level, inside an ORB, message transfer,…
  –  …
 General Organization for Secure Object

 Security policies are specified by means of policy objects
Security policy determines the selection of security services
           Replaceable Security Services

•    Implementation is hidden behind standard interfaces
•    Access control interceptor checks the access rights (access control)
•    Secure invocation interceptor takes care of message protection
•    Vault object creates secure context
                   Distributed Objects
   Java                                        CORBA

   RMI               Java IDL                 Orbacus               OrbixWeb

•  From Sun        •  Java ORB core        •  Java ORB core         •  IIOP to
•  Integrates      •  idlgen Tool          •  jidl tool available      ORBs for all
   with Java       •  IIOP module             for most major           vendors
•  Objects            connects to other       platforms             •  Accessible
   addressed via      vendors              •  Integrates well          already
   URLs            •  Lightweight TCP/        with jdk              •  Premiere
                      IP connects to       •  Available free for       commercial
                      other Java servers      non commercial           product
                   •  From Sun                use from              •  Expensive

To top