Distributed Objects and Remote Invocation

1
Distributed Objects and Remote Invocation
2
Introduction

• Distributed Applications Applications that are
  designed to have cooperating programs that run in
  several different processes.
• Several familiar programming models that have
  been extended to distributed programs
• Move from conventional procedure call to Remote
  Procedure Call (in different processes).
• Remote Method Invocations allows different
  objects to call each others.
• Objects receive notification if other objects
  have been changed by some external events.

3

• Visibility Object B is Visible to Object A if
  and only if A can invoke Methods defined in
  Object B.
• Types of visibility
• Object B is a parameter to some function in
  object A.
• Object B is defined as a member variable in
  Object A.
• Object B is declared globally for Object A.
• Object B is defined in some function in Object A.

4

• RPC is the same of RMI in the case of using
  objects environment.
• Middleware
• It is a software that provides programming model
  above the basic building blocks of processes and
  messages passing between objects.
• An important aspect in middleware is the location
  transparency.
• There is an independency from the details of
  communication protocol, OS, and HW.

5

• Location Transparency it is not important for
  the client where is the object is located whether
  in the same system or in other system. Also the
  same thing for the event-based programs to
  compose Distributed Systems, because it is not
  important where are the objects that make the
  events and where the objects that receive these
  events.
• Communication Protocols Protocols that support
  the middleware abstraction are independent from
  the networking protocols (request-reply protocol
  is independents from TCP or UDP).

6

• Computer Hardware there is no difference between
  different architectures, middle ware will handle
  that.
• OS the services activities provided by
  middleware are independent from the Operating
  Systems used.
• Use of several Programming Languages Middleware
  has the capability to allow using different
  programming languages. (different objects from
  different PLs).

7
Interfaces

• Modularity most programs are designed as set of
  modules that communicate with each others.
• This communication can be by procedure calls, or
  by direct access to variables in another modules
  (public).
• Interface must be defined for each module in
  order to control the possible interactions
  between these modules.
• Interface for a module provides a mechanism for
  how to use services for that modules (procedures
  and variables).
• Interfaces considered as protections for that
  data in the module, they allow access to specific
  data.

8

• Interfaces in the distributed systems
• it is not allowed for a module to access variable
  in another module in the same process in the DS.
  Middleware breaks this rule by using getters and
  setters for the module.
• Caller and receiver in different process call
  by value and call by reference are not allowed.
• Parameters are sent from module to another by
  messages (input).
• The result of the call output are parameters
  returned from the module by a message.

9

• Pointers cant be transmitted between modules
  because they are different if defined in
  different processes. (different Computers).
• Service Interface is the way the Server provides
  its services, it describes for the clients how to
  use different functions defined in the server
  (its a contract)-this is in client server model.
• Remote Interface is how the object will invoke
  another objects methods, how the inputs and
  outputs will take place.

10
Communication between distributed objects

• The Object Model.
• Distributed Objects.
• Distributed Object Model.
• Design Issues for RMI.
• Implementation of RMI.

11
The Object Model

• Object-Oriented Program is composed of
  interacting Objects that invoke methods.
• Object set of data set of methods.
• Encapsulation.
• In non-distributed system, there is possibility
  for accessing public variables.
• In distributed systems, there must be setters and
  getters.

12

• Object References variables that hold an object.
• To invoke a method in the object, object
  reference must be followed by the method name and
  the list of arguments (if there are).
• Target or Receiver Object is the object that its
  method is invoked.
• First-class values are object references that
  are assigned to other variables, passed as
  arguments, or returned as return values.

13
Interfaces

• Interfaces for objects are the specification of
  the objects, it provides a complete description
  about the object (its methods and there
  arguments, their return values ad how and where
  they can be used) without specifying their
  implementation (encapsulation).
• In Java, a class may have several interfaces.

14

• Actions an action in object-oriented program is
  initiated by the client object in order to invoke
  a method defined in the server object.
• The control passed from the client to the server,
  and when the server executed its method, the
  control returns back to the client.
• Invoking a method can result in
• Change in receiver state.
• Invoking another methods in another objects.
  (state machine diagram).
• An event happened, triggers an action or an
  activity. (ex hydroponics gardening system).

15

• Exceptions programmers need to take in mind that
  system may have some errors during run time, so
  exceptions ease the writing of code in order to
  prevent these errors to take place (ex reading
  from file, division by Zeros, wrong
  argumentetc).
• A block of code can Throw an exception to run
  another code in the case of a problem.
• This means that control passes to the catch Bock
  in the case of exception.

16

• Garbage Collection it is a way for freeing the
  memory from objects that are not used anymore.
• Java has its own Garbage Collector.
• C does not have, programmer has to free it in
  its program (using destructors).

17
Distributed Objects

• State of the object its variables with their
  values.
• The sate of the program consists of its different
  objects states.
• In RMI, a message is a method invocation on one
  object from another object, both of them may
  reside in different processes.
• To allow a chain of related invocations, objects
  in some servers that act as servers, may act as
  clients and invoke other messages on another
  server objects in another systems.

18

• Encapsulation is very important in the case of
  using distributed objects, in order o enhance
  security.
• This means that the state of a server object can
  be changed only by its methods.

19
The distributed object model

• Each process contains a collection of objects.
• Some of these objects can receive remote and
  local invocations, others receive local
  invocations only.

20

• Figure 1.
• B and F are remote Objects.
• Object C has a reference to Object E, so it can
  invoke a method in E. (E is visible to C).
• Remote Object Reference object that can run
  methods on remote object must has a remote object
  reference for that object. A must has remote
  object reference for B.
• Remote interface every remote object must has an
  interface which specifies which methods can be
  invoked remotely.

21

• Remote Reference Object is a unique number that
  is assigned for a particular object in order to
  make it remote object, and this reference can be
  passed as argument and result of remote method
  invocation. (Like cardinality in Object Model).
• Remote interfaces it is a set of rules, that
  make an object just to invoke specified methods
  in another object. In this case object a has an
  interface for object b.

22

• The usefulness of Interfaces, is that, you dont
  need to know what is the programming language
  used in implementing a remote object in order to
  invoke its interface methods, instead, you can do
  that using any programming language considered as
  object based programming language.

23
(No Transcript)
24

• Actions in Distributed Object Systems as in
  non-distributed systems, there is some action
  that makes an invocation of some method in an
  object, but with the difference in that this
  invocation takes place between different
  processes or different computers.
• When the invocation passes the boundaries for the
  process, it is converted to RMI, and in this case
  the remote object reference must be specified.
• Back to figure 1, object A may might obtain a
  reference for Object F using Object B.

25

• Garbage Collection in Distributed Systems if
  using JAVA for example, RMI system must provide
  automated Garbage Collection by default. This
  will be discussed in detail later.
• Exceptions the distributed system may fail
  during to any reason. For example, a process that
  contains the remote object may be too busy to
  reply, or the computer that holds the whole
  process may fail or crash.
• So, RMI must be able to throw exceptions

26
Design Issues for RMI

• There are many ways to ensure implementing the
  RMI.
• Retry Request Message whether to retransmit the
  request message until either a reply is received
  or the server is assumed to have a fail.
• Duplicate Filtering when retransmissions are
  used, server has to identify duplicate requests.
• Retransmission of results whether to keep a
  history of result messages to enable lost results
  to be retransmitted without re-executing the
  operations at the server.

27

• The previous points provide several semantics for
  the reliability of the system.
• Invocation semantics
• Maybe invocation semantics the invoker cannot
  tell whether the remote method has been executed
  once or not at all. This method of invocation is
  used when no fault tolerance is applied. This
  method has problems
• Omission failures if the invocation or result
  message is lost.
• Crash failures when the server the remote object
  failed.
• If the result message has not been received after
  a timeout and there are no retries, it is
  uncertain whether the method has been executed.
• If the invocation message was lost, then the
  method will not have been executed.
• Or the message is executed and the result was
  lost.
• A crash of the server may occur before or after
  the invocation.

28

• The previous system is called asynchronous, and
  the sender object will not accept the result
  message after time out.
• 2. At-Least once invocation semantics the
  invoker receives either a result, in this case
  the invoker knows that the message was executed
  at the server side, or an exception information
  will be sent to the invoker.
• This method has some problems
• Crash failures when the server containing the
  remote object fails.
• Arbitrary failures. In this case the invocation
  method is retransmitted, the remote object may
  receive the message and execute it more than once
  (Wrong values).

29

• 3- At-most-once invocation the invoker receives
  a result, the invoker here knows that the message
  was executed just once, or an exception
  information in that no result was received, in
  either case the method is executed once or not at
  all.

30

• Transparency there are several implementation
  for transparency, one of these is to make the
  invocation completely transparent (there is no
  difference for the programmer between local calls
  and remote calls of functions), others make the
  invocation for remote method to be explicit in
  the code.

31

• Implementation of RMI

Server
Client
Remote Object B
Skeleton and Dispatcher For Bs Class
Object A
Proxy for B
Request
Reply
Communication Module
Communication Module
Remote Reference Module
Remote Reference Module
32

• Several separate objects are involved in
  achieving a RMI.
• In the previous figure, object A invokes a method
  held by an object B for which it holds a remote
  reference object.
• Communication Module the two cooperating
  communication modules carry out the request-reply
  protocol between client and server.
• The messages between the communication modules
  consist of three parts
• Message type.
• Request ID.
• Remote reference of the object being invoked.
• The communication modules are responsible to
  implement one of the invocation semantics.

33

• The communication module selects the dispatcher
  for the class of the object to be invoked,
  passing in its local reference, which it gets
  from the remote reference module in return for
  the remote object identifier in the request
  message.
• Remote Reference Module its role in translating
  between local and remote object references and
  for creating remote object references.

34

• The remote reference module in each process has a
  remote object table that contains information
  about remote reference object for each object has
  a visibility to it.
• Each table in both sides contains
• entry for all of the remote objects.
• Entry for each local proxy.
• Remote Reference Module actions are
• Create new reference module in the table, if the
  corresponding object is used.
• When a message comes to an object, the remote
  reference will handle it, and create a new remote
  reference if the object does not exist in the
  table, then execute the message.

35

• The table is used to identify which object in the
  process is responsible for handling the message
  that comes to that process.

36
RMI software

• It is a layer of software between the objects of
  the application (distributed objects) and the
  communication (ex. TCP/IP) and the remote
  reference modules.
• Roles of RMI
• Proxy the role of the proxy is make the remote
  method invocation between objects to be
  transparent for the user of the system, illus the
  user (like proxy server works).

37

• It forwards the message to the object outside the
  process.
• It hides the whole process from the user sending
  arguments, receiving results, communication
  processetc.
• One proxy for every remote object.
• 2. Dispatcher one dispatcher for each server
  representing it. The dispatcher receives the
  request message from the communication module,
  uses the methodID to select the appropriate
  object, passing to it the request message.

38

• 3.Skeleton remote object has a skeleton, which
  implements the methods in the remote interface.
  They are implemented in different way than in the
  remote object. It takes the arguments in the
  request, and pass them to the corresponding
  function in the object. It waits till the process
  in the object complete, and then sends back the
  result to the sending proxys method (this result
  may contains exceptions)

39
Server and Client Programs

• The server program contains the classes for the
  dispatcher and skeletons, together with the
  implementations of the classes of all of the
  remote objects it supports. (these classes are
  called servant classes).
• The server program also contains initialization
  section which is responsible for creating and
  initializing at least one of the remote objects
  to be hosted by the server.
• Additional objects may be created according to
  client requests.

40

• The client program will contain the classes of
  proxies for all of the clients it will invoke. It
  uses Binder to look up remote object references.
• Factory Methods remote object interfaces cannot
  contain constructors. So , remote object cannot
  be created by remote invocation on constructors.
• Remote objects created either in the
  initialization section or in methods in a remote
  interface designed for that purpose.
• Factory methods are sometimes referred to methods
  that create remote objects, and factory objects
  are the objects that contain these factory
  methods.
• Any remote object that needs to create remote
  objects for clients must provide methods in its
  remote interface for this purpose.

41

• Binder client programs need a means of obtaining
  a remote object reference for at least one of the
  remote objects held by the server software.
• A binder in a DS is a separate service that
  maintains a table containing mappings from
  textual names to remote object references.
• This table is used by the servers to register
  their remote objects by name, and by clients to
  look up them.

42

• Server Threads when an object executes a method
  on a server, that execution leads to other
  invocations on other servers. This may lead in a
  delay of invocations in order to get the final
  result.
• To avoid the previous problem, designers that
  implement the methods of invocations makes the
  process of invocations to be concurrent.

43

• Activation of remote objects some applications
  need that information kept for long times during
  the execution of the application. But this is not
  the case all the times, because this leads to
  resource wastes.
• To avoid the previous problem, servers that are
  responsible for managing remote objects are
  started when they are needed.
• Processes that started server processes that
  hosts remote objects are called activators.

44

• Active object is the object that is available
  within the running process.
• Passive object is not active during the running
  of the process, but can be active.
• Passive objects becomes active when they invoked.

45

• Persistent Objects the object that lives between
  activation of processes.
• Persistent object stores are responsible for
  keeping track on persistent objects.
• Persistent objects that are no longer needed, are
  deleted.

46

• Object Location the locations of some objects
  sometimes are not always the same. i.e. location
  of remote objects may change to be in different
  process (computers), depending on the
  application. So invoking method(s) on them,
  client object needs to know where to send its
  invocation.
• Location Service is a service that has database
  with remote objects and their probable locations.
  This service helps clients to know where to send
  their invocations.

47
Distributed Garbage Collection

• The main aim for the garbage collector is to free
  the memory from objects that had no references to
  them.
• Java garbage collector based on reference
  counting.
• Whenever a remote reference object involved in a
  process, a proxy will be created and will stay
  there for as long as it is needed.
• The process where the object lives (its server)
  should be informed.
• Later, when there is no proxy for that object (at
  the client side), the server should be informed.

48

• The Distributed Garbage collector works with the
  local Garbage collectors as follows
• Each server process maintains a set of processes
  that hold remote object references for each of
  its remote objects. B.holders is a set of client
  processes that have proxies for object B.
• When a clinet C first receives a remote reference
  to a particular Object , B, it makes an addRef(B)
  invocation to the server of that remote object
  and then creates a proxy, the server adds C to
  B.holders.
• When a client Cs garbage collector notices that
  a proxy for remote object B is no longer
  reachable, it makes a removeRef(B) invocation to
  the corresponding server and then deletes the
  proxy, the server removes C from B.holders.
• When B.holders is empty, the servers local
  garbage collector will release the space occupied
  by B unless there are any local holders.

49

• The previous algorithm is executed when proxies
  are created and deleted. So, executing it will
  not affect the whole systems (make it delayed).
• There is a possibility that one client makes
  removeRef(B) invocation at about the same time as
  another client makes an addRef(B) invocation. If
  the removeRef arrives first and B.holders is
  empty, the remote object B could be deleted
  before the addRef arrives. To avoid this
  situation, if the set B.holders is empty at the
  time when a remote object reference is
  transmitted, a temporary entry is added until the
  addRef arrives.

50

• Remote Procedure Call is the same as RMI in that
  a client program calls a procedure in another
  program running in a server process.
• The server process defines in its service
  interface the procedures that are available for
  calling remotely.
• RPC as RMI implemented to have one of the choices
  of invocation semantics discussed previously.
• RPC is generally implemented over a request-reply
  protocol.
• The main difference is that RPC that there is no
  need for remote reference module, because
  Procedure call is not concerned with objects.

51
Events and Notifications

• The idea behind the use of events is that one
  object can react to a change occurring in another
  object.
• For example, when a user interacts with an
  application by mouse clicks, these interactions
  are seen as events that cause changes in the
  objects that compose the whole application, and
  may change in the whole state of the application.

52

• Distributed event-based systems extend the local
  event model by allowing multiple objects at
  different locations to be notified of events
  taking place at an object.
• Distributed Event-Based Systems has two
  characteristic
• Heterogeneous when using event notifications to
  communicate between objects in different
  processes, these objects can be communicate
  although they are not designed to interoperate.
  All what needed is that, the event-generating
  objects publish the types of events they offer,
  and the other objects subscribe to events and
  provide an interface for receiving notifications.
• Asynchronous Notifications are sent
  asynchronously (without time arrangements like
  emails). There is no need for the server object
  to still wait for the client to send it the
  message, instead the server object can serve
  other clients, and when it receives a message, it
  handles it. (there is no coupling between clients
  and servers).