Distributed systems by G8sE0Un

VIEWS: 0 PAGES: 94

									    Distributed systems


        By. issa al smadi




1
                Distributed Systems
Definitions

   “ A system in which hardware or software components located at
   networked computers communicate and coordinate their actions only
   by message passing . ” [Coulouris]

   “A system that consists of a collection of two or more independent
   computers whish coordinate their processing through the exchange of
   synchronous or asynchronous message passing .”

    “ A distributed system       is   a collection of    independent
   computer .” [ Tanenbaum ].

    “A distributed system is a collection of independent computer
   linked by a network with software designed to produce an integrated
   computing facility.”
     2
         What is a Distributed System ?
 Some comments :

  •System architecture: the machines are autonomous ; this means
  they are computers which, in principle, could work independently;

  • The user’s perception : the distributed system is perceived as a
  single system solving a certain problem (even though, in reality we
  have several computers placed in different locations).

By running a distributed system software the computers are
enabled to :
  -coordinate their activates
  -share resources: hardware, software, data



     3
Reasons for Distributed Systems

    1.    Functional distribution : computers have different
         functional capabilities
            ─ Client / server
            ─ Host / terminal
            ─ Data gathering / data processing

    2.       Load distribution / balancing : assign tasks to
         processors such that the overall system performance is
         optimized.




4
     Reasons for Distributed Systems
3. Replication of processing power : independent processors working
    on the same task:
         distributed systems consisting of collections of microcomputers may have
         processing powers that no supercomputer will ever achieve
         •   10000 CPUs, each running at 50 MIPS, yields 500000 MIPS, then
             instruction to be executed in 0.002 nsec, equivalent to light distance of 0.6
             mm – any processor chip of that size would melt immediately

4.   Physical separation: systems that rely on the fact that computers are
      physically separated (e.g., to satisfy reliability requirements).


5. Economics: collections of microprocessors offer a better price /
    performance ration than large mainframes (mainframes: 10 times faster,
         1000 times as expensive)


     5
          Disadvantages of Distributed System

Difficulties of developing distributed software : how should
operating systems, programming languages and applications look like ?

Networking problems: several problems are created by the network
infrastructure, which have to be dealt with : loss of messages,
overloading,..



Security problems: sharing generates the problem of data security.




    6
         Examples of Distributed Systems
1-The internet
        -Heterogeneous network of computers and applications
        -Implemented through the internet Protocol Stack
        -Typical configuration:




    7
     Examples of Distributed Systems

•Characteristics of Internet
 •Very large and heterogeneous

 •Enables email, file transfer, multimedia communications, WWW, …

 •Open-ended

 •Connects intranets (via backbones) with home users (via modems,
 ISPs)




 8
          Examples of Distributed Systems
2- Intranets
        -Locally administered network
        -Usually proprietary ( e.g., the University campus network (
        -Interface with the Internet
            • firewalls
        - Provides services internally and externally




    9
             Characteristics of intranets

•Several LANs linker by backbones

•Enables info. Flow within organization
       - Electronic data, documents, …
•Provides services
        - Email, file, print services, …
•Often connected to Internet via router
•In / out communications protected by firewall




     10
      Examples of Distributed Systems
3- Mobile and Computing Systems
      1- Cellular phone system (e.g., GSM, UMTS)
          •Resources being shared
              Radio frequencies
              The mobile on the move
      2- Laptop computers
          •Wireless LANs (uni campus WLAN soon to come here?)
      3- Handheld devices, PDAs etc.




 11
                   Mobile & computing
Wireless LANs (WLANs)
   -Connectivity for portable devices (laptops, PDAs, mobile phones,
   video / dig. Cameras,…)
   -WAP (Wireless Applications Protocol)
Home intranet
   -Devices embedded in home appliances (hi-fi, washing machines)
   -Universal ‘remote control’ + communication




     12
            Examples of Distributed Systems
4- Embedded Systems
         1-Avionics ( airplanes engineering ) control system
             •Flight management systems in aircraft
         2-Automotive control system
             •Mercedes S-Class automobiles these days are equipped with 50+
             autonomous embedded processors
            •Connected through proprietary bus-like LANs
         3-Consumer Electronics
            •Audio HiFi equipment




    13
        Examples of Distributed Systems
5- Network file Systems

 1- Architecture to access file systems across a network
 2- Famous example
  •Network File System (NFS), originally developed by SUN Microsystems
   for remote access support in a UNIX context
  •FTP
6- The World Wide Web
 1- Open client-server architecture implemented on top of the Internet
 2- Shared resources
  •Information, uniquely identified through a Uniform Resource Locator
   (URL)


   14
Computer network vs. Distributed Systems
Computer network :the autonomous computers are explicitly visible
(have to be explicitly addressed)
Distributed System : existence of multiple autonomous computer is
transparent
However
    -Many problems in common
    -In some sense networks (or parts of them, e.g., name services)
    are also distributed systems, and
    - Normally, every distributed system relies on services provided
    by a computer network.



  15
     Challenges in the design of Distributed Systems
1. Heterogeneity of:
•   Distributed applications are typically heterogeneous:
    – Different hardware : mainframes, workstations, PCs, servers , etc.;
    – Different software : UNIX ,MS Windows ,IBM OS/2 , Real-time OSs,
        etc.;
    – Unconventional devices : teller machines , telephone switches,
        robots, etc.
    – Diverse networks and protocols: Ethernet, FDDI, ATM, TCP/IP
    – Different Programming language (in particular, data
        representations).
    The solution:
          •   Middleware (e.g., CORBA) : transparency of network ,
              hardware and software and programming language
              heterogeneity.
          •   Mobile Code (e.g., java) ; transparency from hardware and
              software and programming language heterogeneity through
     16
              virtual machine concept.
     Challenges in the design of Distributed Systems
    Challenges in the design of Distributed Systems
    2. Openness
    One of the important features of distributed systems is openness and
    flexibility :
    -        Ensure extensibility and maintainability of systems
    -        Every service is equally accessible to every client (local or remote).
    -        It is easy to implement, install and debug new services
    -        Users can write and install their own services.


•   Key aspect of openness:
    – Standard interfaces and protocols (like internet communication
       protocols)
    –        Support of heterogeneity (by adequate middleware, like CORBA)


        17
               Openness ( cont’d )
The same looking at two distributed nodes


                     Application & services



                        Middleware


         Operating                                 Operating
                         Platform 1




                                      Platform 2
          system                                    system

        Hardware:                                  Hardware:
        Comp.&NW                                   Comp.&NW
           Node 1                                     Node 2


  18
             Openness ( cont’d )
Software Architecture


             Application & services



             Middleware


             Operating system

                                            The platform


          Hardware and computer networked



  19
Challenges in the design of Distributed Systems

3. Security

      -   Privacy
      -   Authentication
      -   Confidentiality :
          Protection against disclosure to unauthorized person.
      -   Integrity:
          protection against alteration and corruption.
      -   Availability:
          Keep the resource accessible



 20
   Challenges in the design of Distributed Systems

   4. Scalability

The system should remain efficient even with a significant increase in the
number of users and resources connected;
   - cost of adding resources should be reasonable
   -Performance loss with increased number of users and resources should
   be controlled
   -Software resources should not run out (number of bits allocated to
   addresses, number of entries in tables , etc.)
   Solution:
           •IP addresses: from 32 to 128 bits


     21
Challenges in the design of Distributed Systems

5. Handling of failures
      -Detection (may be impossible)
      -masking
          •retransmission
          •Redundancy of data storage
      -Tolerance
          •Exception handling (e.g., timeouts when waiting for a web resource)
      -redundancy
          •Redundant routes in network


6. Concurrency
       - Try to Avoid of dead e lock problems.




 22
  Challenges in the design of Distributed Systems

7. Performance
 Several factors are influencing the performance of a distributed
 system :
   1. The performance of individual workstations.
   2. The speed of the communication infrastructure.
   3. Extent to which reliability (fault tolerance ) is provided
      (replication and preservation of coherence imply large
      overheads).
   4. Flexibility in workload allocation: for example, idle processors
      ( workstations) could be allocated automatically to a user’s
      task.


    23
Challenges in the design of Distributed Systems

8. transparency:
 concealing the heterogeneous and distributed nature of the system so that it appears
to the user like one system .

       -Transparency categories
           (according to ISO’s Reference Model for ODP, quoted after [Coulouris ])


           1. Access :access local and remote resources using identical
           operations
            * e.g., network mapped drive using samba server , NFS mounts
           2. Location : access without knowledge of location of a resource
             * e.g., URLs , email addresses



  24
            transparency ( cont’d )
 3. Concurrency : allow several processes to operate
    concurrently using shared resources in a consistent fashion

 3. Replication : The system is free to make additional copies of
    files and other resources (for purpose of performance and / or
    reliability ) , without the users noticing.

     Example :several copies of a file; at a certain request that copy is
           accessed which is the closest to the client .


 5. Failure : allow programs to complete their task despite failures
                  retransmit of email messages




25
6- Mobility : Resources should be free to move from one
   location to another without having their names changed

7- Performance: adaptation of the system to varying load
   situations without the user noticing it. This could be
   achieved by automatic reconfiguration as response to
   changes of the load ; it is difficult to achieve

8-   Scaling : allow system and applications to expand
     without need to change structure or application
     algorithms


26
     Forms of Transparency in a Distributed
                    System
       Transparency     Description

                        Hide differences in data representation and how a
       Access
                        resource is accessed

       Location         Hide where a resource is located

       Migration        Hide that a resource may move to another location

                        Hide that a resource may be moved to another location
       Relocation
                        while in use
                        Hide that a resource may be shared by several
       Replication
                        competitive users
                        Hide that a resource may be shared by several
       Concurrency
                        competitive users

       Failure          Hide the failure and recovery of a resource

                        Hide whether a (software) resource is in memory or on
       Persistence
                        disk
27                    Distributed Computing Systems
                     Communication
•Components of a distributed system have to communicate in order to
interact. This implies support at two levels :
    1.Networking infrastructure (interconnections & network software).
    2.Appropriate communication primitives and models and their
    implementation:
    Communication primitives:
         Send
                        message passing
         Receive
         Remote procedure call (RPC)
    Communication models
         -Client-server communication: implies a message exchange
         between two processes : the process which requests a service
         and the one which provides it;
         -Group multicast : the target of a message is a set of processes,
      `28which are members of a given group .
     Models


29
                           Overview
•System architecture

•Software layer

•Architecture models
   –Client-server , peer processes,…
   –Mobile code , agents

•Design requirements
   –User expectations of the system



     30
                   Distributed design
Customer service

                        Scanner




                                          Data base server




                                  Mainframe




                                  Printer service




 31
                          Architecture
Distribute Systems are foremost highly complex software systems
-Nortel network DMS-100 switch:25-30 million lines of code,3000 software
developers ,20 years life cycle to date.
-Motorola:20% of engineers produce hardware ,80% produce software
-Subject to all kinds of software engineers problems
•Investigation of software Architecture to deal with design challenges
- “…….include the organization of a system as composition of
component:global control structure the protocols for communication
,synchronization,and data access:the assignment of functionality to design
elements the composition of design elements physical distribution scaling and
performance dimension of evolution and selection among design alternatives
this is the software architecture level of design “[garlan and Shaw]
•Architecture paradigms pertinent to distributed systems
- layers
     32
- client-server
                                       Layers
•basic idea
  -Breaking up the complexity of systems by designing them through layers and services
   -layer:group of closely related and highly coherent functionalities
   -service:functionalities provided to superior layer

                                     Layer n+1


                                        Layer n


                                      Layer n-1

•Example of layered architecture
-operating system, ( Kernal , other services )historical :the THE operating system
     33
-computer network protocol architectures
                                    Layers
•Typical layering in Distributed systems


              Application service

                 Middleware

               Operating system

        Computer and network hardware        platform




-platform :Hardware and operating system
-windows NT / Pentium processor

  34
                                  Software Layers

Language an runtime support for                                            Extend services available to
     program interaction                                                  those of the distributed system




                              Applications
                                                   Open ( distributed )
                                                        services

                                      Middleware
Conventional
     and                            Operating system
 distributed                                           platform
 application
                             Computer and network hardware




Responsible for basic
    local resource
management memory
allocation protection
 35
                 Software Layers

Service Layers

        •Higher-level access services at lower layer
        •Services can be located on different computers
        •process type:
                     -server process
                     -client process
                     -peer process



   36
               Important Layers

1- Platform
  • lowest-level hardware + software
  • common programming interface ,
  • different implementation of operating system facilities for
      co-ordination & communication




   37
                        Important Layers
2- Middleware
          Achieve transparency of heterogeneity at platform level
          programming support for distributed computing
Middleware provides
•support for distributed process/objects:
          -suitable for application programming
          -communication via
              –remote method invocation (Java RMI) ,or
              –remote procedure call(sun RPC)
•services infrastructure for application programs
          - security, transaction, event, notification,….
          -products :CORBA,DCOM


     38
                          Models

Models can be used to provide an abstract and simplified
description of certain relevant aspects of distributed systems.

       Model types:
   1.Architectural models define the way responsibilities are
     distributed among components and how they are placed
     in the systems.

   Three architectural models:
            1.Client-server model
            2.Proxy server
            3.Peer processes

  39
                         Models

     2. Interaction models deal with how time is handled
       throughout the system.
      Two interaction models have been introduced:
             1.Synchronous distributed systems
             2.Asynchronous distributed systems


  3. Failure models:
• The failure model specifies what kind of failures can occur
  and what their effects are.
           1.Omission failures
           2.Arbitrary failures
           3.Timing failures

40
                   Architectural models

Architectural models

Define
         -software component (processes ,objects)
         -ways in which components interact
         -mapping of components onto the underlying network

•Why needed?
         -to handle varying environments and usage
         -to guarantee performance


   41
     Client/Server Performance


• Performance, scalability and mobility of the
  client/server model can be improved by
   – Partitioning or replicating data on servers
   – Caching data at proxy servers or clients
   – Using mobile code and mobile agents




42                  Leon Jololian/George Blank     2/7/2013
                   Architectural models
1- Client Server System
1.1 One Tier Architecture




                             Presentation ( to clients )
 Network computer Or PC’s    + processing )transactions , applications )
 with terminal emulation     + data ( management & access )




  43
                        Architectural models
  1- Client Server System
   1.2 Two Tier Architecture


                                                                Client-Server
                                                                “ fat client “
workstation                                                    Or “ fat server”



       Presentation + processing   Data ( remote data access )


          Or presentation
                                   Data processing
                                   ( Remote procedure call )




     44
                      Architectural models
                         Architectural
1- Client Server System
                                         Two tier is satisfactory for simple client-
1.3 Three Tier Architecture              server application , but more demanding
                                         transaction processing application


                              Shared application
                                                                          Shared Data
   clients                    services
                                                                          services




 presentation
                                  processing                data




             Remote data access                Remote data access or
  45         Procedure call                    Transaction processing
                         Client - server
Basic model


                     invocation            invocation


                client                                  Server
                         result   Server
                                           result


                  Client



       :process wishing to access data use resources or
 client
perform operation on different computer
 server : process managing data and all others shared
resources amongst server and client allow     clients
access to resource and performs computation
   46
 interaction :invocation / result message pairs
                            Variants
•-service provided by multiple servers                 Service

                                                     server
                                    client

                                                     server


                                    client
                                                     server


Examples : many commercial webs services are implemented through different
physical server

          -performance (e.g CNN.com,down load servers,etc)
          -reliability
° Server maintain either replicated or distributed database
     47
                         Client - server
Variants
-proxy   servers : render replication / distributedness transparent



                              client                                   Web
                                                                      server
                                                 Proxy
                                                 server

                              client
-Caching                                                               Web
                                                                      server
-proxy server maintains cache store of recently requested resources
-frequently used in search - engines:

Google     (if we search for any page It may take 0.2 sec to find it, but at
second search it will take 0.04 sec

  48
                             proxy server
A proxy server provides copies (replication) of resources which are managed by other
servers.


             client                                          server
                                     Proxy
                                     server
             client                                           server

• Proxy servers are typically used as caches for web resources they maintain a cache
of recently visited web pages or other resources.
when a request is issued by a client the proxy server is first checked if the requested
object (information item) is available there .
• Proxy server can be located at each client or can be shared by several client .
•The purpose is to increase performance and availability , by avoiding frequent
accesses to remote servers.
     49
                      Client - server
Further variants of client-server model
-mobile code
 code that is sent to a client process to carry out a specific task
 - Examples
• Applets
• active messages(containing communications protocol code)
• mobile agents
 - executing program (code+data),migrating amongst processes
,carrying out of an autonomous task, usually on behalf of some other
process .
- Advantages :flexibility ,savings in communications cost
    50
                     Thin clients

executing windows -based user interface on local computer
while application executes on computer server.
   -example : X11 server (run on the application client side)
• mobile devices for mobile computing
    -personal digital assistance ( PDAs)
    -how to connect to internet
         •   wireless LANs/MANs
         •   wireless Personal Area Networks


    51
                            Client - Server
                                                          Music
                                                          service              Alarm
                                        gateway                                server


                             Internet                Hotel wireless
                                                                               Camera
                                         discovery
                                          service
                                                                      laptop    PDA     Guest device
                                                        TV/PC
• Further variants of client-server model

-spontaneous networking
- characteristics
     * W-LAN confronted with constantly changing set of heterogeneous mobile devices
     * Devices roaming in heterogeneous W-LAN environments
- Benefits
     * no need for wire line connection
     * Easy access to locally available services

     52
                                    Client - server
                                                         Music
                                                         service              Alarm
                                        gateway                               server


                             Internet               Hotel wireless
                                                                              Camera
                                        discovery
                                         service
                                                                                       Guest device
●     Further variant of client - server mode          TV/PC         laptop    PDA

* spontaneous networking

     -Challenges

1.      support for convenient (easy) connection and integration:
              ● internet assumes device has IP address in fixed sub-network
2.     Intermittent (distortions ) connectivity of devices
       ●    unavailable when in tunnels , airplanes ,etc.
3.     Privacy             ubiquity of location information
4.     security
      1- access to device         2- access right in dynamic
       53
                                      Client - server
                                               Music
                                               service             Alarm
                       gateway                                     server

            Internet                   Hotel wireless

                       discovery                                   Camera
                       Discovery
                         service                                    PDA
                        service           TV/PC           laptop
Further variant of client - server mode
* spontaneous networking
-Discovery      services
 *services available in the network
 * their properties ,and how to access them ( including device-specific driver information )

-Interfaces     of discovery services
 * registration service
 accept registration requests from servers , stores properties in database of currently available
services
 * lookup services
      54
 match requested services with available services
                            Client - server
Interfaces
 • use of client-server architecture has impact on the software architecture used

     -what are the synchronization mechanisms between client and server
     -admissible types of request/responses

 Design challenges
• quality of service
   - performance       1- response times    2- throughput

  - reliability
  - adaptability

• dependability
   - fault tolerance : system is expected to continue to function correctly in the
         presence of fault
     55
   - security
          Fundamental interaction Model
• Performance characteristics of communication channels
   * latency: delay between sending and receipt of message
      - network access time (e.g , Ethernet retransmission delay)
      - time for first bit to travel from senders network interface to
   receivers network interface
      - processing time with in the sending and receiving processes
  * throughput: number of unit (e.g, packets) delivered per time unit
  * band width: amount of information (e.g,bits) transmitted per time
                unit
  * delay jitter : variation in delay between different message of the
                  same type (e.g,video frames in ATM networks)

     56
         Fundamental interaction Model
synchronous distributed system
  * time to execute each step of computation within a process has known lower and upper
bounds
  * message delivery times are bounded to known value
  * each process has a clock whose drift rate from real times is bounded by a known value
• Asynchronous distributed system : (no bounds on)
         * process execution times
         * message delivery times
         * clock drift rate
• Note
  * synchronous distributed systems are easier to handle but determining realistic bounds
can be hard or impossible
  * asynchronous systems are more abstract and general : a distributed algorithm
executing on one system is likely to also work on another one
       57
   Synchronous Distributed Systems
Main features:
    •        lower and upper bounds on execution time of processes can be set
    •        transmitted messages are received within a known bounded time
    •        drift rates between local clocks have a known bound
Important consequences :
1. Only synchronous distributed system have a predictable behavior in terms of
timing only such systems can be used for hard real-time application
2. In a synchronous distributed system it is possible and safe to use timeouts in
order to detect failures of a process or communication link .
** it is difficult and costly to implement synchronous distributed systems.



        58
 Asynchronous Distributed Systems
* Many distributed systems (including those on the internet) are
asynchronous.
    • No bound on process execution time (nothing can be assumed about
    speed , load , reliability of computers).
    • No bound on message transmission delays(nothing can be assumed
    about speed , load , reliability of interconnections).
    • No bounds on drift rates between local clocks.


     Important consequences:
 1. In an asynchronous distributed systems there is no global physical time
        Reasoning can be only in terms of logical time
 2. Asynchronous distributed systems are unpredictable in terms of timing.
 3. No timeouts can be used.
     59
  The “Happened Before “ Relation
• Lamport defined the happened before relation (denoted as “                    “), which
         describes a casual ordering of events:

  (1) if a and b are events in the same process, and a occurred before b, then
         a     b

  (2) if a is the event of sending a message m in one process, and b is the event
         of receiving that message m in another process, then a                     b

  (3) if a         b , and b         c , then a           c (i.e., the relation “       “ is
      transitive
Causality:
    * past events influence future events
    * this influence among casually related events (those that can be ordered
      by “         “ ) is referred to as casual affects
    60
     * if a         b , event a casually affects event b
                          Failure Models

What kind of failures can occur and what are there effects ?
• Omission failures
• Arbitrary failures
• Timing failures


** Failures can occur both in processes and communication channels
,the reason can be both software and hardware .
** Failure models are needed in order to build systems with predictable
behavior in case of failures (systems which are fault tolerant ).



     61
                    Omission failure
A processor or communication channel fails to perform actions it is
supposed to do .

This means that the particular action is not performed !

We do not have an omission failure if :

• An action is delayed (regardless how long) but finally executed.
•An action is executed with an erroneous result.
If we are sure that messages arrive, a timeout will indicate that the
Sending process has crashed. Such a system has a fail-stop behavior




     62
                                          Failures
          Process p                                                     Process q

    Outgoing       Send m                                                      Receive
    message buffer

                                    Communication channel
Omission Failures
                                                                                        Incoming
●Process omission failures: process crashes
                                                                                        message buffer
•      Detection with timeouts
•      Crash is fail-stop if other processes can detect with certainty that process has crashed
●Communication omission failures: message is not being delivered (dropping of messages)
     possible causes:
•      Network transmission error
•      Receiver incoming message buffer overflow

Arbitrary failures
● Process: omit intended processing steps or carry out unwanted ones
    63
● Communications channel: e.g., non-delivery, corruption or duplication
                        Failures
 Class of failure    Affects                description


Fail-stop            process   process halts and remains halted. Other
                               processes may detect this state

Crash                process   Process halts and remains halted. Other processes
                               may not be able to detect this state.
Omission            Channel    A message inserted in an outgoing message buffer
                               never arrives at the other end’s incoming message
                               buffer
Send-omission       process    A process completes a send, but the message is not
                               put in it’s outgoing message buffer
Receive-omission    process    A message is put in process’s incoming message
                               buffer, but that process does not receive it .
Arbitrary           Process    Process/channel exhibits arbitrary behavior: it may
                               send/transmit arbitrary message at arbitrary times.
(Byzantine)         or         Commit omissions: a process may stop or taken an
                               incorrect step.
                    channel
   64
                        Timing failures
                                      description
     Class of Failure      Affects



                           Process    Process’s local clock
     Clock                            exceeds the bounds on
                                      its
                                      rate of drift from real
                                      time.
     performance           Process    Process exceeds the
                                      bounds on the interval
                                      between two steps.

                           channel    A message’s
     performance                      transmission takes
                                      longer than the
                                      stated bound

65
              Security Model


     The security of a DS can be achieved
     by securing the processes and the
     channels used in their interactions and
     by protecting the objects that they
     encapsulate    against     unauthorized
     access.

66
                Performance
•Responsiveness

    - fast interactive response delayed remote
requests
    -use of caching, replication

•Throughput

     -dependent on speed of server and data
transfer

•Load balancing
   67 -Use of applets, multiple servers
•To model security threats, we postulate an enemy
that is capable of sending any process or
reading/copying message between a pair of processes
•Threats form a potential enemy: threats to processes,
threats to communication channels, and denial of
service.
  68
     Object Interaction:

       RMI and RPC


69
                    Overview
• Distributed applications programming
        - distributed objects model
        - RMI, invocation semantics
        - RPC
         Products
        - Java RMI,CORBA,DCOM
        - Sun RPC
        - JINI

  70
                   Why Middleware?
• Location transparency
       - client/server need not know their location
• Sits on top of OS, independent of:
   - communication protocols:
        use abstract request-reply protocols over UDP,TCP
   - computer hardware:
        use external data representation e.g. CORBA CDR
   - operating system:
        use e.g. socket abstraction available in most systems
   - programming language:
        e.g. CORBA supports Java, C++
  71
          Middleware Layer



           Applications
       RMI , RPC and events
                                    Middleware
       Request-reply protocol         layer
     External data representation
         Operating System




72
                          Objects
        object
                                              object

                          interface
         Data                                 Data

        Implementation   m1           m4      Implementation
          of methods     m2           m5        of methods
                         m3




• Objects = data + methods


• Interact via interfaces:
     - define types of arguments and exceptions of methods

73
                  The object model
• Programs logically partitioned into objects
   - distributing objects natural and easy
• Interfaces
   - the only means to access data, make them remote?
• Actions
   - via method invocation
   - interaction, chains of invocations
   - may lead to exceptions, part of interface
• Garbage collection
   - reduced effort, error-free (Java, not C++)
   74
         The distributed object model
                                  C
                           LOCAL            LOCAL
              REMOTE     INVOCATION       INVOCATION     REMOTE
            INVOCATION                                 INVOCATION


                            B                                       F
     A                                       E
                           LOCAL
                         INVOCATION
                                      D




• Objects distributed (client-server models)
• Extend with
   - Remote object reference
   - Remote interfaces
   - Remote method invocation (RMI)
   75
 Advantages of distributed objects
• Data encapsulation gives better protection
   - concurrent processes, interference
• Method invocations
   - can be remote or local
• Objects
   - can act as clients, servers, etc
   - can be replicated for fault-tolerance and performance
   - can migrate, be cached for faster access
  76
         Remote Object Reference
• Object References
  - used to access objects which live in processes
  - can be passed as arguments, stored in variables,…
• Remote Object References
  - object identifiers in a distributed system
  - must be unique in space and time
  - error returned if accessing a deleted object
  - can allow relocation
  77
            Remote Object Reference
• Constructing unique remote object reference
   - IP address, port, interface name
   - time of creation, local object number (new for each
   object)
• Use the same as for local object references
• If used as addresses
   - cannot support relocation
         32 bit          32 bit     32 bit     32 bit
   Internet address   Port number   time     Object     Interface of remote
                                             number     object

  78
                 Remote interfaces
• Specify externally accessed
   - variables and procedures
   - no direct references to variables (no global memory)
   - local interface separate
• Parameters
   - input, output or both,
   - instead of call by value, call by reference
• No pointers
• No constructors
   79
   Remote Object and its interfaces

                                        Remote object
                                                               Local
                    Remote                                   interface
                   interface              Data

                               m1                       m4
                               m2     Implementation    m5
                               m3       Of method       m6




• CORBA: Interface Definition Language (IDL)
• Java RMI: as other interfaces, keyword remote
  80
          Handling remote objects
• Exceptions
   - raised in remote invocation
   - clients need to handle exceptions
   - timeouts in case server crashed or too busy


• Garbage collection
   - distributed garbage collection may be necessary
   - combined local and distributed collector



    81
                          RMI issues
• Local invocations
   -executed exactly once


• Remote invocations
   - via Request-Reply
   - may suffer from communication failures!
         • retransmission of request/reply
         • message duplication, duplication filtering
   - no unique semantics...

    82
            Invocation semantics summary

                     Fault tolerance measures                                     Invocation

                                                                                  semantics


Retransmit request                  Duplicate          Re-execute procedure
   message                          filtering           or retransmit reply


 No                          Not applicable         Not applicable                 Maybe
 Yes                          No                Re-execute procedure          At-least-once
 Yes                          Yes               Retransmit reply              At-most-once



       83
             Re-executing a method sometimes dangerous...
                    Maybe invocation
• Remote method
   - may execute or not at all, invoker cannot tell
   - useful only if occasional failures

• Invocation message lost…
   - method not executed

• Result not received…
   - was method executed or not?

• Server crash…
   - before or after method executed?
   - if timeout, result could be received after timeout...
  84
               At-least-once invocation
• Remote method
   - invoker receives result (executed exactly) or exception (no result,
   executed once or not at all)
   - retransmission of request message
• Invocation message retransmitted…
   - method may be executed more than once
   - arbitrary failure (wrong result possible)
   - method must be idempotent (repeated execution has the same
   effect as a single execution)
• Server crash…
     85
   - dealt with timeouts, exceptions
             At-most-once invocation

• Remote method
   - invoker receives result (executed once) or exception (no
   result)
   - retransmission of reply & request messages
   - duplicate filtering
• Best fault-tolerance…
   - arbitrary failures prevented if method called at most once
• Used by CORBA and Java RMI


    86
             Transparency of RMI
•should remote method invocation be same as local?
– Same syntax
– need to hide
   •data marshalling
   •IPC calls
   •locating/contacting remote objects

•Problems
– different RMI semantics?      susceptibility to failures?
– Protection against interference in concurrent scenario?

• Approaches (Java RMI)
– transparent,but express differences in interfaces
– provide recovery features
     87
                      Implementation of RMI
                                                            Server
                   Client
           object A proxy for B
                                    Request
                                                           Skeleton       Remote object B
                                                         &dispatcher
                                                         for B’s class



                                        Reply
Remote reference            Communication
                                                Communication
module                                                               Remote reference
                               module
                                                   module            module




Object A invokes a method in a remote object B:
communication module reference module,RMI software.
      88
          Communication modules

•Reside in client and server

•Carry out Request-Reply jointly
– use unique message ids (new integer for each message)
– implement given RMI semantics

•Server’s communication module
– selects dispatcher within RMI software
– converts remote object reference to local




     89
           Remote reference module
•Creates remote object references and proxies

•Translates remote to local references (object table):
– correspondence between remote and local object references (proxies)

•Directs requests to proxy (if exists)

•Called by RMI software
– when marshalling / unmarshalling




     90
          RMI Software architecture
•Proxy
   – behaves like local object to client
   – forwards requests to remote object

•Dispatcher
   – receives request
   – selects method and passes on request to skeleton

•skeleton
   – implements methods in remote interface
   – unmarshals data, invokes remote object
   – Waits for result, marshals it and returns reply
     91
            Remote Procedure Call (RPC)

•RPC
– historically first,now little used
– over Request-Reply protocol
– usually at-least-once or at-most-once semantics
– can be seen as a restricted form of RMI
–sun RPC

•RPC software architecture
– similar to RMI (communication,dispatcher and stub in place of
proxy / skeleton)


     92
                  RPC client and server

           Client process
                                                     Server process
                                  Request


           Client stub             Reply
           procedure                                           Server stub
                         Communication
                                         Communication         procedure
Client program           module                                              Service
                                         module          dispatcher          procedure




  Implemented over Request-Reply protocol
      93
                       Summary

•Distributed object model
   – capabilities for handling remote objects (remote
   references,etc)
   – RMI:maybe,at-least-once,at-most-once semantics
   – RMI implementation,software architecture
• Other distributed programming paradigms
   – RPC,restricted form of RMI, less often used
   – event notification (for heterogeneous,asynchronous systems)



    94

								
To top