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 can’t 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 (it’s a contract)-this is in client server model.
Remote Interface: is how the object will invoke another object’s 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 argument…etc).
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 don’t 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.

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. Invocation semantics:
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. This method has some problems:
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 B’s 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 process…etc.
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 proxy’s 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 C’s 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 server’s 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 s). 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).