1. Distributed Computing
Selo
2 Agustus 2005

2. Outline Distributed Computing RMI CORBA Comparasion RMI vs CORBA
summary

3. Distributed Computing
Distributed computing is an application design model in which the program, data and the actual computation is spread across the network

4. Distributed Computing
(You can think about) Distributed computing: braking down an application into individual computing agents that can be distributed on a network of computers, yet still work together to do cooperative tasks.

5. Motivations
use of small available computers instead of larger (unavailable) ones;
not to move (huge) data;
fault tolerance (if a machine or agent goes down, the job can still carry on); …

6. Example of Distributed Computing
How are “transactions” executed between a client ATM and a bank server?
Bank Database: Think of two simultaneous deposits of $10,000 into your bank account, each from one ATM.
Both ATMs read initial amount of $1000 concurrently from the bank server
Both ATMs add $10,000 to this amount (locally at the ATM)
Both write the final amount to the server
What’s wrong?
The ATMs need mutually exclusive access to your account entry at the server

7. Distributed Programming
low level: sending data among distributed computations
network is visible (to the programmer)
programmer must deal with many details
higher level: supporting invocations among distributed computations
network is invisible (to the programmer)
programmer focuses on application

8. Remote Procedure Call

9. Remote Object Systems

10. Anatomy processes; threads; objects; agents.
: (a significant functional element of a distributed application)

11. Issues to face when developing distributed systems
partitioning and distributing data and functions;
flexible, extendible communication protocol;
security issues,
generating stubs/proxies
serialization or arguments and return values
heterogeneity of data representations
locating servers in a distributed environment
authentication of called and calling procedures
semantics of invocation

12. Distributed Computing Techniques
Sockets
Remote Procedural Call
Java Message Services
Remote Method Invocation
CORBA
DCOM

13. provide a protocol for transmitting data over a network.
Distribution schemes
CORBA, RMI, …
provide a protocol for transmitting data over a network.

14. Middleware Layers Applications RPCs and RMIs, e.g., CORBA Middleware
Provide
support to the
application
Request reply protocol
External data representation
Operating System
RPCs and RMIs, e.g., CORBA
RMI=Remote Method Invocation
CORBA=Common Object Request Brokerage Architecture

15. Remote Method Invocation

16. What is RMI ? 
Remote method invocation (RMI) is the action of invoking a method of a remote interface on a remote object.
Java RMI is a distributed object model that makes distributed object easy to implement and to use.

17. Remote Method Invocation
After a client is bound to an object, it can invoke the object’s method through the proxy.
Such a remote method invocation (RMI) is similar to a RPC with respect to marshaling and parameter passing.
The difference is that RMI supports systemwide object references.

18. Remote Method Invocation
An interface definition language is used in RMI to specify the object’s interface.
Static invocation implies using object-based languages (e.g., Java) to predefine interface definitions.
Dynamic invocation permits composing a method invocation at run-time.

19. Remote Method Invocation
Client Process
Proxy object is a hollow container of Method names.
Remote Reference Module translates between local and remote object references.
Proxy
Object B
Object A
Remote Reference Module
Comm. Module
Server Process
Dispatcher sends the request to Skeleton Object
Skeleton unmarshals parameters, sends it to the object, & marshals the results for return
Comm. Module
Remote Reference Module
Dispatcher
Object B
Skeleton
for B’s Class
MIDDLEWARE

20. Remote Reference Module
Is responsible for translating between local and remote object references and for creating remote object references.
Has a remote object table
An entry for each remote object held by the process. E.g., B at P2.
An entry for each local proxy. E.g., B at P1.
When a remote object is seen by the remote reference module, it creates a remote object reference and adds it to the table.
When a remote object reference arrives in a request or reply message, the remote reference module is asked for the corresponding local object reference, which may refer to either a proxy or to a remote object.
In case the remote object reference is not in the table, the RMI software creates a new proxy and asks the remote reference module to add it to the table.

21. Proxy
Is responsible of making RMI transparent to clients by behaving like a local object to the invoker.
The proxy implements (Java term, not literally) the methods in the interface of the remote object that it represents. But,…
Instead of executing an invocation, the proxy forwards it to a remote object.
Each method of the proxy marshals the following into a request message: (i) a reference to the target object, (ii) its own method Id and (iii) the argument values. Request message is sent to the target, then proxy awaits the reply message, un-marshals it and returns the results to the invoker.

22. Marshalling & Unmarshalling
External data representation: an agreed, platform-independent, standard for the representation of data structures and primitive values.
CORBA Common Data Representation (CDR)
Allows a Windows client (little endian) to interact with a Unix server (big endian).
Marshalling: the act of taking a collection of data items (platform dependent) and assembling them into the external data representation (platform independent).
Unmarshalling: the process of disassembling data that is in external data representation form, into a locally interpretable form.

23. What about Server Side? Dispatcher and Skeleton
Each process has one dispatcher, and a skeleton for each local object (actually, for the class).
The dispatcher receives the request message from the communicating module.
It uses the method Id to select the appropriate method in the skeleton, passing on the request message.
Skeleton implements the methods in the remote interface.
A skeleton method un-marshals the arguments in the request message and invokes the corresponding method in the remote object.
It waits for the invocation to complete and marshals the result, together with any exceptions, in a reply message.

24. Java RMI 
Distributed objects have been integrated in the Java language with a goal of a high degree of distribution transparency.
Java adopts remote objects as the only form of distributed objects. [i.e., objects whose state only resides on a single machine]
Java allows each object to be constructed as a monitor by declaring a method to be synchronized.

25. What does Java provide? Object Oriented environment;
abstract interfaces;
platform independence;
fault tolerance through exception handling;
network support;
security (runtime environment, secure remote transactions);
multithreading support.

26. Java RMI However there are problems with distributed synchronization.
Thus, Java RMI restricts blocking on remote objects only to the proxies.
This means remote objects cannot be protected against simultaneous access from processes operating on different proxies by using synchronization methods.
Explicit distributed locking techniques must be used.

27. Java Remote Object Invocation
Any primitive or object type can be passed as a parameter to an RMI provided the type can be marshaled. [i.e, it must be serializable.]
Platform dependent objects such as file descriptors and sockets cannot be serialized.
In Java RMI reference to a remote object is explained on slide 14.
A remote object is built from a server class and a client class.

28. Java Remote Object Invocation
Proxies are serializable in Java.
This means proxies can be marshaled.
In actually an implementation handle is generated, specifying which classes are needed to construct the proxy.
The implementation handle replaces the marshaled code as part of a remote object reference.
This passing of proxies as parameters works only because each process is executing the same Java virtual machine.

29. Java RMI Architecture

30. Java RMI Client Server Interaction

31. Java RMI Security Manager
Since RMI involves access to/from a foreign host, and possibly object downloading, it is important for both the server and the client to protect its system from malicious access.
The RMISecurityManager is a class provided Java, and can be instantiated in both the client and the server for limiting access priviledges.
You can write your own security manager, if so desired.
try {
System.setSecurityManager(new
RMISecurityManager( )); }
catch { …}

32. Algorithm for building an RMI Application
Server side:
Open a directory for all the files to be generated for this application.
Specify the remote-server interface, and compile it to generate the interface class file.
Build the remote server class by implementing the interface, and compile it using javac.
Use rmic to process the server class to generate a stub.class file and a skelton.class file: rmic SomeServer
If stub downloading is desired, copy the stub file to an appropriate directory on the HTTP host.
Activate the RMIRegistry, if it has not already been activated.
Set up a java.policy file.
Activate the server, specifying (i) the codebase if stub downloading is desired, (ii) the server host name, and (iii) the security policy file.

33. Alogorithm for building an RMI Application
Client side:
Open a directory for all the files to be generated for this application.
Implement the client program or applet, and compile it to generate the client class.
If stub downloading is not in effect, copy the server interface stub class file by hand.
Set up a java.policy file.
Activate the client, specifying (i) the server host name, and (ii) the security policy file.

34. CORBA

35. Why CORBA
The needs of distributed computing arise in 1980s, the central characteristics of which are:
Distributed applications – i.e. applications that run on a network of machines
The integration of legacy applications into new systems
The use of different programming languages to write new components or to wrap legacy codes

36. Solution prior to CORBA
Remote procedure calls (RPCs)
Enabling functions to be invoked by clients on one machine and executed by servers on a different machine
Low-level; provides very little in the way of encapsulation
Other problems include queuing of requests, event notification, transaction management…

37. CORBA – an Integration of RPCs and Object Oriented Concept
Gives rise to notions of distributed components and interface-based programming
Clients program to an interface where different implementations of the interface (components) are possible
Notions like inheritance, delegation, dynamic binding are kept in CORBA

38. What Does CORBA Bring to Us?
A uniformity to a disparate and varied world of computing
Interoperability among largely distinct, distributed, and legacy programs
Fostering the development of open architectures – i.e., designs that are more easily evolvable and maintainable

39. Essential CORBA concepts
A CORBA component is an object
A CORBA interface is specified in CORBA IDL
A CORBA class implements one or more CORBA interfaces
CORBA is programming-language neutral
The execution of a CORBA component is location transparent

40. Distributed Objects
Distributed objects are partitioned into sets; all objects in a set belongs to the same process.
Each set is identified an a pair (M,P) where M is a unique machine name and P is a process id
Machine M1
Process P1
Machine M2
Process P2
Machine M2
Process P7

41. IDs and Names of Objects
All CORBA objects have globally unique identifiers called Interoperable Object References (IORs), which are machine generated and not intended for human use
A named object has a well-known, unique, human-friendly name that clients use to access it
A server process advertises one or more named objects; client processes have no named objects

42. Access to Remote Objects
Clients access remote objects via references --- light-weight objects that have the same interface as remote objects, except their task is to forward all methods invocations to the server for remote object execution
References can be exchanged among processes, but the location of the remote objects remains unchanged.

43. Access to Remote Objects (cont.)
named remote object
unnamed object
reference

44. Object Request Broker (ORB)
Runs in every CORBA process, responsible for communicating with other ORBs
Acts as a message bus between objects
Interacts with each other via General Inter-ORB Protocol (GIOP)

45. What an ORB Does Locate the object to which the message is to be sent
If the object is at another process, pass the message to the ORB of that process
If the object is within the same process as the ORB, ensures that the object is ready to receive the request and pass the parameters to the object

46. CORBA Interface Definition Language (IDL)
IDL is the basis of CORBA interface-centric programming, which enables the development of language-neutral interfaces that CORBA objects implements.
Language-specific compilers will translate IDL specifications into language-specific source codes that is used to implement those interfaces

47. Interface Centric Programming
Suppose the server is written in language L1, and the client is written in L2
Define the interface (I) of server object by CORBA IDL (language neutral)
Compile I to I’ written in L1; the server object implements I’
Compile I to I’’ written in L2

48. Interface Centric Programming (cont.)
The client object creates a reference of the the server object that has I’’ as its interface
Whenever the client object needs to call the server object to perform some operation, it calls the corresponding method of the reference instead.
CORBA will automatically forward the method call to the remote server object

49. IDL Syntax Based on C++ concepts and syntax
Supports typedefs, unions, enumerated types, sequences
Needs language-specific compilers to translate it into language-specific interface – will not be discussed here

50. Modules
A module is a basic unit that defines a distributed application
A module has three parts: structure definition, exception definition and interface definition
module M {
struct S1 {…};
struct S2 {…}; …
exception E1 {…};
interface I1 {…}; };

51. Structures A structure is a named sequence of data members
The type of a data member can be CORBA primitive types, another structure, or an interface
struct MyData {
short x;
string y;
AnotherStruct s;
MyInterface o; };

52. Exceptions The standard way of processing errors in CORBA
Syntactically identical to structures – it has a name and a list of public data members that are to be transmitted with the exception
exception Oops {
string whatiswrong;
long exceptioncode; };

53. Interfaces
Interfaces of remote objects are defined by the interface declaration
An IDL interface I is a sequence of one or more constants and/or method declaration
interface I {
// constant declarations
// method declarations };

54. An Example Written in CORBA IDL
//M.idl
Module M {
exception Oops {
string whatisworng; };
interface MyInfo {
string name;
void setName( in string aName); }
interface InfoManager {
void register ( in MyInfo info ) raises (Oops);
boolean find ( in string name, out MyInfo info);

55. Summary
CORBA is an infrastructure for building distributed applications, Servers advertise named objects with known interfaces. Client uses these names to create references to server objects in order to invoke their methods.

56. Summary (cont.)
CORBA objects are created within the confines of a process which executes object request broker (ORBs). The ORB handles all inter-process communication among different CORBA objects, and largely hides the ugly details of writing distributed systems.

57. Summary (cont.)
CORBA is based on interface-centric programming. CORBA designs center around language-neutral interfaces that CORBA objects implement. The centerpiece pf CORBA is its interface definition language (IDL), the language in which language-neutral interfaces are expressed. Language-specific compilers translate IDL specifications to language-specific source code.

58. Comparasion CORBA vs RMI

59. Invocation Semantics Fault tolerance measures Invocation semantics
whether to keep a
history of result
messages to enable
lost results to be
retransmitted without
re-executing the
operations
Whether or not to
retransmit the request
message until either
a reply is received or
the server is assumed
to be failed
when retransmissions
are used, whether to
filter out duplicate
requests at the server.
Fault tolerance measures
Invocation
semantics
Retransmit request
message
Duplicate
filtering
Re-execute procedure
or retransmit reply No
Yes
Not applicable
At-least-once
Maybe
CORBA
(ok for idempotent operations)
Java RMI,
CORBA
Idempotent=same result if applied repeatedly

60. Generation of Proxies, Dispatchers and Skeletons
In CORBA, programmer specifies interfaces of remote objects in CORBA IDL; then, the interface compiler automatically generates code for proxies, dispatchers and skeletons.
In Java RMI
The programmer defines the set of methods offered by a remote object as a Java interface implemented in the remote object.
The Java RMI compiler generates the proxy, dispatcher and skeleton classes from the class of the remote object.

61. Binder and Activator
Binder: A separate service that maintains a table containing mappings from textual names to remote object references. (sort of like DNS)
Used by servers to register their remote objects by name. Used by clients to look them up. E.g., Java RMI Registry, CORBA Naming Svc.
Activation of remote objects
A remote object is active when it is available for invocation within a running process.
A passive object consists of (i) implementation of its methods; and (ii) its state in the marshalled form.
Activation creates a new instance of the class of a passive object and initializes its instance variables. It is called on demand.
An activator is responsible for
Registering passive objects (recording the names of the servers against the names of the passive objects)
Starting named server processes and activating remote objects in them.
Keeping track of the locations of the servers for remote objects it has already activated
E.g., Activator=Inetd, Passive Object/service=FTP (invoked on demand)

62. Selesai