Distributed Objects and Remote Invocation 5'1 Introduction

1
Distributed Objects and Remote Invocation 5.1
Introduction

• Foci
• Communication among distributed objects via RMI
• Recipients of remote invocations are remote
  objects, which implement remote interfaces for
  communication
• Reliability
• Either one or both the invoker and invoked can
  fail, and status of communication is supported by
  the interface (e.g., notification on failures,
  reply generation, parameter processing
  marshalling/unmarshalling)
• Local invocations target local objects, and
  remote invocations target remote objects
• Distributed even-based systems - subscription
  to events as they occur at remote sites of
  interest and receipt of notification therefrom
• Subscription/notification paradigm supports
  heterogeneity and asynchrony (e.g., the Jini
  distributed event-driven specification)

2
Distributed Objects and Remote Invocation 5.1
Introduction

• Programming models for distributed
  programs/applications
• RPC client programs call procedures in server
  programs, running in separate and remote
  computers (e.g., Unix RPC)
• RMI extensions of object-oriented programming
  models to allow a local method (of a local
  object) to make a remote invocation of objects in
  a remote process (e.g., Java RMI)
• EBP (event-based programming) model allows
  objects anywhere to receive notification of
  events that occur at other objects of which
  interests have been registered (e.g., Jini EBP)
• Chapter 5 focus on RMI and EBP paradigms
• Issues
• Distributed object communication
• Design and implementation of RMI and RPC
• EBP design and implementation

3
Distributed Objects and Remote Invocation 5.1
Introduction

• Middleware
• A suite of API software that uses underlying
  processes and communication (message passing)
  protocols to provide its abstract protocol
  simple RMI request-reply protocol
• The middleware provides location transparency,
  protocol abstraction, OS, and hardware
  independence, and multi-language support

4
Distributed Objects and Remote Invocation 5.1
Introduction

• Middleware
• Location transparency RPC client calls appear
  to be local and remote procedure could be on any
  remote server RMI remote objects location is
  transparent and in EBP models sources of object
  event/notification is transparent
• Protocol transparency the middleware
  request-reply protocol can be built on top of
  lower-level TCP or UDP
• Hardware transparency Issues with different data
  representations, conversions, and instruction set
  are transparent
• OS all three paradigms could run on top of any
  OS platform

5
Distributed Objects and Remote Invocation 5.1
Introduction

• Remote Object Interfaces
• Interfaces hide the details of modules providing
  the service and access to module variables is
  only indirectly via getter and setter methods
  / mechanisms associated with the interfaces
• (e.g., call by value/reference for local calls
  through pointers vs. input, output, and inout
  paradigms in rmi/rpc through message-data and
  objects)
• An interface is a set of language facilities
  (syntax/semantics) or notation for mapping
  input/output parameters in a remote
  invocation/call onto native normal handling of
  parameters
• Such APIs allow uniformity of both local and
  remote invocation (same syntax and denotational
  semantics)
• IDL Provide a generic template of interfaces
  for objects in different languages to perform
  remote invocation among each other
• E.g., CORBA IDL (Fig 5.2), Sun XDR for RPC, Jave
  RMI, OSF DCE for RPC in C

6
Distributed Objects and Remote Invocation 5.2
Communication

• By means of RMI
• The object model
• Distributed objects (object-based distributed
  systems)
• The distributed object model (extensions of the
  basic object model for distributed object
  implementation)
• The design issues (of RMI) (local once-or-nothing
  invocation semantics vs. remote invocation
  semantics similarities or differences)
• The implementation issues (mapping the middleware
  to lower-layer facilities)
• Distributed garbage collection issues (an
  application algorithmic)

7
Distributed Objects and Remote Invocation 5.2
Communication

• The object model
• Objects (in classes) encapsulate methods and data
  variables, with some variables being directly
  accessible and communication via passing
  arguments and receiving results from (locally)
  invoked objects
• Object references objects or variables holding
  instances of objects are accessed via references.
  Accessing target/receiver objects requires
  reference.methodname(args) and references can be
  passed as args, too.
• Interfaces the signature of a set of object
  methods arg type, return values, and
  exceptions. Objects providing interfaces
  typically offer internal implementations of
  methods of the interfaces. E.g., a class may
  implement several interfaces, and an interface
  may be implemented by any class
• Actions effect of method invocation may affect
  receiver/target or cause chain reaction to
  complete, including results and exception
  propagation
• Exceptions For clarity and cleanness of code,
  object methods lists exception conditions that
  can be thrown and handlers/blocks-of-code written
  to handle/catch the exceptions as they occur
• Garbage collection reclaiming freed object
  spaces Java (automatic), C (user supplied)

8
Distributed Objects and Remote Invocation 5.2
Communication

• Distributed objects
• State of an object current values of its
  variables
• State of an object (in OO context) depends of
  how the objects are partitioned or distributed in
  the program space and the programming model
• CS objects reside with client and server
  processes or computers
• RMI method invocations and associated messages
  are exchanged by c/s depending on where the
  objects reside
• When objects are replicated for performance and
  fault-tolerance, or migrated for performance and
  availability, objects are thus distributed
• Distributing objects require encapsulation for
  effective, secure, protected object state (All
  data are accessed directly by their respective
  methods, and requires authorization.)
• Concurrent access to distributed objects is
  protected (due to encapsulation, and use of,
  e.g., condition variables for synchronization)
• Heterogeneity (of data types) is supported via
  interface-methods

9
Distributed Objects and Remote Invocation 5.2
Communication

• The distributed object model
• extensions to the basic object model supporting
  both local and remote method invocation of
  objects (with transparency) in processes. Some
  objects can effect only local invocation, and
  others remote invocation, and others can have
  both
• RMI invocations between objects in different
  processes (either on same or different computers)
  is remote. Invocations within the same process
  are local
• each process contains objects, some of which can
  receive remote invocations, others only local
  invocations
• those that can receive remote invocations are
  called remote objects
• objects need to know the remote object reference
  of an object in another process in order to
  invoke its methods. How do they get it?
• the remote interface specifies which methods can
  be invoked remotely

10
Distributed Objects and Remote Invocation 5.2
Communication
Figure 5.3

• Objects receiving remote invocations (service
  objects) are remote objects, e.g., B and F
• Object references are required for invocation,
  e.g., C must have Es reference or B must have
  As reference
• B and F must have remote interfaces (of their
  accessible methods)

11
Distributed Objects and Remote Invocation 5.2
Communication

• Remote object references
• An unique identifier of a remote object, used
  throughout a distributed system
• The remote object reference (including the
  interface list of methods) can be passed as
  arguments or results in rmi
• Remote interfaces
• Remote objects have a class that implement remote
  methods (as public).
• In Java, a remote interface class extends the
  Remote interface
• Local objects can access methods in an interface
  plus methods implemented by remote objects
  (Remote interfaces cant be constructed no
  constructors)

12
Distributed Objects and Remote Invocation 5.2
Communication

• Actions in distributed object systems
• Local activations plus remote invocations that
  could be chained across different
  processes/computers. Remote invocation activate
  the RMI interface using the remote object
  reference (identifier)
• Example of chaining In Figure 5.3 Object A
  received remote object reference of object F from
  object B
• Distributed garbage collection
• Achieved by cooperation between local
  (language-specific) collectors and a designated
  module that keeps track of object
  reference-counting (See details and examples in
  5.2.6, using an algorithm based on pairwise
  request-reply comm with at-most-once invocation
  semantics between the reference modules in the
  processes using proxies.)
• Exceptions
• Possible problems remote process is busy, dead,
  suspended to reply, or lost reply which will
  require timeout-retry in an exception handler
  implemented by the invoker/client
• Usually, there are standard exceptions which can
  be raised plus others users implement

13
Distributed Objects and Remote Invocation 5.2
Communication

• Design Issues of RMI
• Local invocations have at-most-once or
  exactly-once semantics
• Distributed RMI, there alternative semantics are
• Retry request message retransmit until reply is
  received or on server failure at-least-once
  semantics
• Duplicate message filtering discard duplicates
  at server (using seq s or ReqID)
• Buffer result messages at server for
  retransmission avoids redo of requests (even
  for idempotent ops) at-most-once semantics

14
Distributed Objects and Remote Invocation 5.2
Communication

• Invocation semantics failure model
• Maybe, At-least-once and At-most-once can suffer
  from crash failures when the server containing
  the remote object fails.
• Maybe - if no reply, the client does not know if
  method was executed or not
• omission failures if the invocation or result
  message is lost
• At-least-once - the client gets a result (and the
  method was executed at least once) or an
  exception (no result)
• arbitrary failures. If the invocation message is
  retransmitted, the remote object may execute the
  method more than once, possibly causing wrong
  values to be stored or returned.
• if idempotent operations are used, arbitrary
  failures will not occur
• At-most-once - the client gets a result (and the
  method was executed exactly once) or an exception
  (instead of a result, in which case, the method
  was executed once or not at all)

15
RMI Implementation The architecture of remote
method invocation (with transparency)
Figure 5.6
RMI software - between application level objects
and communication and remote reference modules

16
Distributed Objects and Remote Invocation 5.3
RPC

• RPC
• Similar to RMI but calls are made to remote
  procedures and can have chain-reaction effect
• Server process defines the callable procedures
  in its service interface, have at-most-once or
  at-least-once invocation semantics
• Implemented using request-reply protocol
  (without ROR)
• There is one stub procedure for each procedure
  in the interface (like RMI proxy marshalls
  procedure id and arguments into message, and
  unmarshalls results on return)
• Server has dispatcher (like RMI) with one server
  stub procedure and its service procedure for each
  procedure in the interface
• Server stub procedure (like RMI skeleton
  method) unmarshalls arguments in calls, calls
  corresponding procedure, and marshalls results in
  a reply message

17
Distributed Objects and Remote Invocation 5.3
RPC
18
Distributed Objects and Remote Invocation 5.4
Events Notification
19
Distributed Objects and Remote Invocation 5.4
Events Notification
20
Java Remote interfaces Shape and ShapeList

• Note the interfaces and arguments
• GraphicalObject is a class that implements
  Serializable.

Figure 5.11
import java.rmi. import java.util.Vector public
interface Shape extends Remote int
getVersion() throws RemoteException GraphicalObj
ect getAllState() throws RemoteException publ
ic interface ShapeList extends Remote Shape
newShape(GraphicalObject g) throws
RemoteException Vector allShapes() throws
RemoteException int getVersion() throws
RemoteException
21
Java class ShapeListServer with main method

• Probably skip this one

import java.rmi. public class
ShapeListServer public static void main(String
args) System.setSecurityManager(new
RMISecurityManager()) try ShapeList
aShapeList new ShapeListServant() 1
Naming.rebind("Shape List", aShapeList
) 2 System.out.println("ShapeList server
ready") catch(Exception e)
System.out.println("ShapeList server main "
e.getMessage())
Figure 5.13
22
Java class ShapeListServant implements interface
ShapeList

• Probably skip this one

import java.rmi. import java.rmi.server.Unicast
RemoteObject import java.util.Vector public
class ShapeListServant extends UnicastRemoteObject
implements ShapeList private Vector
theList // contains the list of Shapes 1
private int version public ShapeListServant()thr
ows RemoteException... public Shape
newShape(GraphicalObject g) throws
RemoteException 2 version Shape s
new ShapeServant( g, version) 3
theList.addElement(s)
return s public Vector allShapes()throws
RemoteException... public int getVersion()
throws RemoteException ...
Figure 5.14
23
Java client of ShapeList
import java.rmi. import java.rmi.server. imp
ort java.util.Vector public class
ShapeListClient public static void
main(String args) System.setSecurityManager(ne
w RMISecurityManager()) ShapeList aShapeList
null try aShapeList (ShapeList)
Naming.lookup("//bruno.ShapeList") 1 Vector
sList aShapeList.allShapes() 2
catch(RemoteException e) System.out.println(e.get
Message()) catch(Exception e)
System.out.println("Client "
e.getMessage())

• Probably skip this one

Figure 5.15
24
Summary

• Heterogeneity is an important challenge to
  designers
• Distributed systems must be constructed from a
  variety of different networks, operating systems,
  computer hardware and programming languages.
• The Internet communication protocols mask the
  difference in networksand middleware can deal
  with the other differences.
• External data representation and marshalling
• CORBA marshals data for use by recipients that
  have prior knowledge of the types of its
  components. It uses an IDL specification of the
  data types
• Java serializes data to include information about
  the types of its contents, allowing the recipient
  to reconstruct it. It uses reflection to do
  this.
• RMI
• each object has a (global) remote object
  reference and a remote interface that specifies
  which of its operations can be invoked remotely.
• local method invocations provide exactly-once
  semantics the best RMI can guarantee is
  at-most-once
• Middleware components (proxies, skeletons and
  dispatchers) hide details of marshalling, message
  passing and object location from programmers.