Distributed Objects

1
Distributed Objects
2
Message Passing vs. Distributed Objects
3
Message Passing versus Distributed Objects

• The message-passing paradigm is a natural model
  for distributed computing, in the sense that it
  mimics interhuman communications. It is an
  appropriate paradigm for network services where
  processes interact with each other through the
  exchanges of messages.
• However, the abstraction provided by this
  paradigm does not meet the needs of the
  complexity of sophisticated network applications.

4
Message Passing versus Distributed Objects 2

•  Message passing requires the participating
  processes to be tightly-coupled throughout their
  interaction, the processes must be in direct
  communication with each other. If communication
  is lost between the processes (due to failures in
  the communication link, in the systems, or in one
  of the processes), the collaboration fails.
• The message-passing paradigm is data-oriented.
  Each message contains data marshalled in a
  mutually agreed upon format, and is interpreted
  as a request or response according to the
  protocol. (e.g., 1000-character message)
• The receiving of each message triggers an action
  in the receiving process. It is inadequate for
  complex applications involving a large mix of
  requests and responses. In such an application,
  the task of interpreting the messages can become
  overwhelming.

5
The distributed object paradigm

• The distributed object paradigm is a paradigm
  that provides abstractions beyond those of the
  message-passing model. As its name implies, the
  paradigm is based on objects that exist in a
  distributed system.
• In object-oriented programming, objects are used
  to represent an entity significant to an
  application. Each object encapsulates
• the state or data of the entity in Java, such
  data is contained in the instance variables of
  each object
• the operations of the entity, through which the
  state of the entity can be accessed or updated.

6
object-oriented programming

• To illustrate, consider objects of the
  DatagramMessage class. Each object instantiated
  from this class contains three state data
  items--a message, the senders address, and the
  senders port number. In addition, each object
  contains four operations
• a method putVal, which allows the values of these
  data items to be modified,
• a getMessage method, which allows the current
  value of the message to be retrieved, and
• a getAddress method, which allows the senders
  address to be retrieved.
• a getPort method, which allows the senders port
  to be retrieved.

7
object-oriented programming
public class DatagramMessage private String
message private InetAddress
senderAddress private int senderPort
public void putVal(String message, InetAddress
addr, int port) this.message message
this.senderAddress addr
this.senderPort port public String
getMessage( ) return this.message
public InetAddress getAddress( ) return
this.senderAddress public int getPort( )
return this.senderPort // end
class
8
Local Objects vs. Distributed Objects

• Local objects are those whose methods can only be
  invoked by a local process, a process that runs
  on the same computer on which the object exists.
  
• A distributed object is one whose methods can be
  invoked by a remote process, a process running on
  a computer connected via a network to the
  computer on which the object exists.

9
The Distributed Object Paradigm

• In a distributed object paradigm, network
  resources are represented by distributed objects.
  To request services from a network resource, a
  process invokes one of its operations or methods,
  passing data as arguments to the method. The
  method is executed on the remote host, and the
  response, if any, is sent back to the requesting
  process as a returned value.

10
Message Passing versus Distributed Objects

• Compared to the message-passing paradigm, which
  is data-oriented, the distributed objects
  paradigm is action-oriented the focus is on the
  invocation of the operations/methods, while the
  data passed takes on a secondary role. Although
  less intuitive to human-beings, the
  distributed-object paradigm is more natural to
  object-oriented software development.

11
The Distributed Object Paradigm - 2

• A process running in host A makes a method call
  to a distributed object residing on host B,
  passing with the data as arguments, if any.
• The method call invokes an action performed by
  the method on host B, and a returned value, if
  any, is passed from host B to host A.
• A process which makes use of a distributed object
  is said to be a client process of that object,
  and the methods of the remote object are called
  remote methods (as opposed to local methods, or
  methods belonging to a local object) to the
  client process.

12
The Distributed Objects Paradigm
13
An Archetypal Distributed Objects System
Server Objects need to be registered in an
object registry, e.g., RMI registry.
14
Distributed Object System - 1

• A distributed object is provided/registered, by a
  process--object server.
• A facility, here called an object registry, must
  be present in the system architecture for the
  distributed object to be registered.
• To access a distributed object, a process an
  object client looks up the object registry for
  a reference1 to the object. This object
  reference will be used by the object client to
  make calls to the methods.
• 1 A reference is a handle for an object it
  is a representation through which an object can
  be located in the computer where the object
  resides.

15
Distributed Object System - 2

• Logically, the object client makes a call
  directly to a remote method.
• In reality, the call is handled by a software
  component, called a client proxy/stub, which
  interacts the software on the client host that
  provides the runtime support for the distributed
  object system.
• The runtime support is responsible for the
  interprocess communication needed to transmit the
  call to the remote host, including the
  marshalling of the argument data that needs to be
  transmitted to the remote object.

16
Distributed Object System - 3

• A similar architecture is required on the server
  side, where the runtime support for the
  distributed object system handles the receiving
  of messages and the unmarshalling of data, and
  forwards the call to a software component called
  the server proxy/skeleton.
• The server proxy interfaces with the distributed
  object to invoke the method call locally (on the
  remote host), passing in the unmarshalled data
  for the arguments.
• The method call results in the performance of
  some tasks on the server host.
• The outcome of the execution of the method,
  including the marshalled data for the returned
  value, is forwarded by the server proxy to the
  client proxy, via the runtime support and network
  support on both sides.

17
Distributed Object Systems/Protocols

• The distributed object paradigm has been widely
  adopted in distributed applications, for which a
  large number of mechanisms based on the paradigm
  are available. Among the most well known of such
  mechanisms are
• Java Remote Method Invocation (RMI),
• the Common Object Request Broker Architecture
  (CORBA) systems,
• the Distributed Component Object Model (DCOM),
• mechanisms that support the Simple Object Access
  Protocol (SOAP).
• Of these, the most straightforward is the Java
  RMI

18
From Remote Procedure Call to Remote Method
Invocation
19
Remote Procedure Calls (RPC)

• Remote Method Invocation (RMI) has its origin in
  a paradigm called Remote Procedure Call (RPC)
• In the RPC model, a procedure call is made by one
  process to another, with data passed as
  arguments.
• Upon receiving a call, the actions encoded in the
  procedure are executed, the caller is notified of
  the completion of the call, and a returned value,
  if any, is transmitted from the callee to the
  caller.

20
Local Procedure Call and Remote Procedure Call
21
Remote Procedure Calls (RPC) - 2

• Since its introduction in the early 1980s, the
  Remote Procedure Call model has been widely in
  use in network applications.
• There are two prevalent APIs for this paradigm.
• the Open Network Computing (ONC) Remote Procedure
  Call, evolved from the RPC API originated from
  Sun Microsystems in the early 1980s.
• The other well-known API is the Open Group
  Distributed Computing Environment (DCE) RPC.
• Both APIs provide a tool, rpcgen, for
  transforming remote procedure calls to local
  procedure calls to the stub.

22
Java Remote Method Invocation
23
Remote Method Invocation

• Remote Method Invocation (RMI) is an
  object-oriented implementation of the Remote
  Procedure Call (RPC) model. It is an API for
  Java programs only.
• Using RMI, an object server exports a remote
  object and registers it with a directory service
  (e.g., RMI registry). The object provides remote
  methods, which can be invoked in client programs.
  
• Syntactically
• A remote object is declared with a remote
  interface, a Java interface.
• The remote interface is implemented by the object
  server.
• An object client accesses the object by invoking
  the remote methods associated with the objects
  using syntax provided for remote method
  invocations.

24
The Java RMI Architecture
25
Object Registry

• The RMI API allows a number of directory services
  to be used1 for registering a distributed
  object.
• We will use a simple directory service called the
  RMI registry, rmiregistry, which is provided with
  the Java Software Development Kit (SDK)2.
• The RMI Registry is a service whose server, when
  active, runs on the object servers host machine,
  by convention and by default on the TCP port
  1099.
• 1 One such service is the Java Naming and
  Directory Interface (JNDI), which is more general
  than the RMI registry, in the sense that it can
  be used by applications that do not use the RMI
  API.
• 2 The Java SDK is what you download to your
  machine to obtain the use of the Java class
  libraries and tools such as the java compiler
  javac .

26
The interaction between the stub and the skeleton

• A time-event diagram describing the interaction
  between the stub and the skeleton

27
The API for the Java RMI

• The Remote Interface
• The Server-side Software
• The Remote Interface Implementation
• Stub and Skeleton Generations
• The Object Server
• The Client-side Software

28
The Remote Interface

• A Java interface is a class that serves as a
  template for other classes it contains
  declarations or signatures of methods whose
  implementations are to be supplied by classes
  that implement the interface.
• A java remote interface is an interface that
  inherits from the Java java.rmi.Remote
  interface, which allows the interface to be
  implemented using RMI syntax.
• Other than the Remote extension (inheritance) and
  the Remote exception (exceptions handling) that
  must be specified with each method signature, a
  remote interface has the same syntax as a regular
  or local Java interface.

29
A sample remote interface

• // file SomeInterface.java
• // to be implemented by a Java RMI server class.
• import java.rmi.
• public interface SomeInterface extends Remote
• // signature of first remote method
• public String someMethod1( )
• throws java.rmi.RemoteException
• // signature of second remote method
• public int someMethod2( float ) throws
  java.rmi.RemoteException
• // signature of other remote methods may follow
• // end of interface

30
A sample remote interface - 2

• The java.rmi.RemoteException must be listed in
  the throw clause of each methods signature.
• This exception is raised when errors occur during
  the processing of a remote method call, and the
  exception is required to be caught in the method
  callers program.
• Causes of such exceptions include exceptions that
  may occur during interprocess communications,
  such as access failures and connection failures,
  as well as problems unique to remote method
  invocations, including errors resulting from the
  object, the stub, or the skeleton not being found.

31
The Server-side Software

• A server object provides the methods of the
  interface to a distributed object. Each server
  object must
• implement each of the remote method specified in
  the interface,
• register an server object, which contains the
  method implementation, with a directory service
  (e.g., RMI registry or JNDI).
• It is recommended that the two parts be provided
  as separate classes.

32
The Remote Interface Implementation

• A server class implements the remote
  interface--SomeInterface. The syntax is similar
  to a class that implements a local interface.
• import java.rmi.
• import java.rmi.server.
• // This class implements the remote interface
  SomeInterface.
• public class SomeImpl extends UnicastRemoteObject
• implements SomeInterface
• public SomeImpl() throws RemoteException
• super( )
• public String someMethod1( ) throws
  RemoteException
• // code to be supplied
• public int someMethod2( ) throws
  RemoteException
• // code to be supplied
• // end class

33
UML diagram for the SomeImpl class
inherits from
implements
34
The Object Server

• The object server class is a class whose code
  instantiates and exports an object of the remote
  interface implementation.
• import java.rmi.
• public class SomeServer
• public static void main(String args)
• try// code for port number value to be
  supplied
• SomeImpl exportedObj new SomeImpl()
• startRegistry(RMIPortNum) // launch RMI
  registry
• // register the object under the name
  some
• registryURL"rmi//localhost"portNum
  "/some"
• Naming.rebind(registryURL, exportedObj)
• System.out.println("Some Server
  ready.")
• // end try
• // end main

35
The Object Server - 2

• // This method starts a RMI registry on the local
  host, if it
• // does not already exists at the specified port
  number.
• private static void startRegistry(int RMIPortNum)
• throws RemoteException
• try
• Registry registry LocateRegistry.getRegistry(R
  MIPortNum)
• registry.list( )
• // The above call will throw an exception
• // if the registry does not already
  exist
• catch (RemoteException ex)
• // No valid registry at that port.
• System.out.println(
• "RMI registry cannot be located at port "
  RMIPortNum)
• Registry registry LocateRegistry.createRegist
  ry(RMIPortNum)
• System.out.println(
• "RMI registry created at port "
  RMIPortNum)
• // end startRegistry

36
The Object Server - 3

• In our object server template, the code for
  exporting an object is as follows
• // register the object under the name some
• registryURL"rmi//localhost" portNum
  "/some
• Naming.rebind(registryURL, exportedObj)
• The Naming class provides methods for storing and
  obtaining references from the registry. In
  particular, the rebind method allow an object
  reference to be stored in the registry with a URL
  in the form of
• rmi//lthost namegtltport numbergt/ltreference
  namegt
• The rebind method will overwrite any reference in
  the registry bound with the given reference name.
  If the overwriting is not desirable, there is
  also a bind method.
• The host name should be the name of the server,
  or simply localhost. The reference name is a
  name of your choice, and should be unique in the
  registry.

37
The Object Server - 4

• When an object server is executed, the exporting
  of the distributed object causes the server
  process to begin to listen and wait for clients
  to connect and request the service of the object.
  
• An RMI object server is a concurrent server each
  request from an object client is serviced using a
  separate thread of the server. Note that if a
  client process invokes multiple remote method
  calls, these calls will be executed concurrently
  unless provisions are made in the client process
  to synchronize the calls.

38
Stub and Skeleton Generations

• In RMI, each distributed object requires a proxy
  for the object server and the object client,
  known as the objects skeleton and stub
  respectively.
• These proxies are generated from the
  implementation of a remote interface using the
  RMI compiler rmic.
• rmic ltclass name of the remote interface
  implementationgt
• For example
• Unixgt rmic SomeImpl
• As a result of the compilation, two proxy files
  will be generated, each prefixed with the
  implementation class name
• SomeImpl_skel.class
• SomeImpl_stub.class.

39
The stub file for the object

• The stub file for the object, as well as the
  remote interface file, must be shared with each
  object client these file are required for the
  client program to compile.
• A copy of each file may be provided to the object
  client by hand. In addition, the Java RMI has a
  feature called stub downloading which allows a
  stub file to be obtained by a client dynamically
  through HPPT.

40
The RMI Registry

• A server exports an object by registering it by a
  symbolic name with a server known as the RMI
  registry.
• // Create an object of the Interface
• SomeInterfacel obj new
  SomeInterface(Server1)
• // Register the object w/ registry
  rebind will overwrite existing //
  registration by same name bind( ) will not.
• Naming.rebind(//localhost/Server1, obj)
• A server, called the RMI Registry, is required to
  run on the host of the server which exports
  remote objects.
• The RMIRegistry is a server located at port 1099
  by default
• It can be invoked dynamically in the server
  class
• import java.rmi.registry.LocateRegis
  try
• LocateRegistry.createRegistry (
  1099 )

41
The RMI Registry - 2

• Alternatively, an RMI registry can be activated
  by using the rmiregistry utility which comes with
  the Java Software Development Kit (SDK), as
  follows
• unixgt rmiregistry ltport numbergt
• where the port number is a TCP port number. If
  no port number is specified, port number 1099 is
  assumed.
• The registry will run continuously until it is
  shut down (via CTRL-C, for example)

42
The Client-side Software

• The program for the client class is like any
  other Java class.
• The syntax needed for RMI involves
• locating the RMI Registry in the server host,
• and
• looking up the remote object reference for the
  server object the object reference can then be
  cast to the remote interface class and the remote
  methods can be invoked.

43
The Client-side Software - 2

• import java.rmi.
• .
• public class SomeClient
• public static void main(String args)
• try
• String registryURL
• "rmi//localhost" portNum "/some"
• SomeInterface reObjRef
• (SomeInterface)Naming.lookup(registryURL)
  
• // invoke the remote method(s)
• String message reObjRef.method1()
• System.out.println(message)
• // method2 can be invoked similarly
• // end try
• catch (Exception e)
• System.out.println("Exception " e)
• //end main
• //end class

44
Looking up the remote object

• The lookup method of the Naming class is used to
  retrieve the object reference, if any, previously
  stored in the registry by the object server.
• The retrieved reference must be cast to the
  remote interface (not its implementation class).
• String registryURL
• "rmi//localhost" portNum "/some"
• SomeInterface reObjRef
• (SomeInterface)Naming.lookup(registryURL)
  

45
Invoking the Remote Method

• The remote interface reference can be used to
  invoke any of the methods in the remote
  interface, as in the example
• String message reObjRef.method1()
• System.out.println(message)
• The syntax for the invocation of the remote
  methods is the same as for local methods.
• It is a common mistake to cast the object
  retrieved from the registry to the interface
  implementation class or the server object class .
  Instead it should be cast as the remote
  interface.

46
Internet Inter-ORB Protocol (IIOP)
----------------------- Application Objects
----------------------- ORB
----------------------- IIOP
----------------------- TCP
----------------------- IP
----------------------- Ethernet
----------------------- Physical Device
-----------------------
47
RMIC with IIOP option

• rmic -iiop
• Causes rmic to generate IIOP stub and tie
  classes, rather than JRMP (Java Remote Method
  Protocol) stub and skeleton classes.
• A stub class is a local proxy for a remote object
  and is used by clients to send calls to a server.
  
• Each remote interface requires a stub class,
  which implements that remote interface. A
  client's reference to a remote object is actually
  a reference to a stub.
• Tie classes are used on the server side to
  process incoming calls, and dispatch the calls to
  the proper implementation class. Each
  implementation class requires a tie class.
• Invoking rmic with the -iiop generates stubs and
  ties that conform to the following naming
  convention
• _ltimplementationNamegt_stub.class
  _ltinterfaceNamegt_tie.class

48
Java Naming and Directory Interface

• The Java Naming and Directory Interface (JNDI) is
  an application programming interface (API) that
  provides naming and directory functionality to
  applications written using the Java programming
  language.
• The JNDI architecture consists of an API and a
  service provider interface (SPI). Java
  applications use the JNDI API to access a variety
  of naming and directory services. The SPI enables
  a variety of naming and directory services to be
  plugged in transparently.
• Naming Service names are associated with objects
  and objects are found based on their names.
• Directory service. a directory service associates
  names with objects and allows such objects to
  have attributes. Thus, you not only can look up
  an object by its name but also get the object's
  attributes or search for the object based on its
  attributes.

From http//java.sun.com/products/jndi/tutorial/
getStarted/overview/index.html
49
Java Naming and Directory Interface
From http//java.sun.com/products/jndi/tutorial/
getStarted/overview/index.html
50
COS Naming Service - 1

• The CORBA COS (Common Object Services) Naming
  Service provides a tree-like directory for object
  references much like a filesystem provides a
  directory structure for files. The Naming Service
  provided with Java IDL is an implementation of
  the COS Naming Service specification. The
  following overview is taken from that document.
• A name-to-object association is called a name
  binding. A name binding is always defined
  relative to a naming context. A naming context is
  an object that contains a set of name bindings in
  which each name is unique. Different names can be
  bound to an object in the same or different
  contexts at the same time.
• To resolve a name is to determine the object
  associated with the name in a given context. To
  bind a name is to create a name binding in a
  given context. A name is always resolved relative
  to a context - there are no absolute names.

From http//java.sun.com/j2se/1.4.2/docs/guide/i
dl/jidlNaming.htmlexample1
51
COS Naming Service - 2

• Because a context is like any other object, it
  can also be bound to a name in a naming context.
• Binding contexts in other contexts creates a
  naming graph - a directed graph with nodes and
  labeled edges where the non-leaf nodes are
  contexts, and leaf nodes are object references.
• A naming graph allows more complex names to
  reference an object. Given a context in a naming
  graph, a sequence of names can reference an
  object. This sequence of names (called a compound
  name) defines a path in the naming graph to
  navigate the resolution process.

52
COS Naming Service - 3

• plans is an object reference
• Personal is a naming context that contains two
  object references calendar and schedule.
• From http//java.sun.com/j2se/1.4.2/docs/guide/i
  dl/jidlNaming.htmlexample1

53
RMI-IIOP Sample Code- interfaceImpl

• // interface
• public interface HelloInterface extends
  java.rmi.Remote public void sayHello( String
  from ) throws java.rmi.RemoteException
• // Interface implementation
• public class HelloImpl extends PortableRemoteObjec
  t implements HelloInterface
• public HelloImpl() throws java.rmi.RemoteExceptio
  n super() // invoke rmi linking and
  remote object initialization
• public void sayHello( String from ) throws
  java.rmi.RemoteException
  System.out.println( "Hello from " from "!!"
  ) System.out.flush()

54
RMI-IIOP Sample Code- Server

• public class HelloServer
• public static void main(String args)
• try
• // Step 1 Instantiate the Hello
  servant
• HelloImpl helloRef new HelloImpl()
• // Step 2 Publish object reference
  in the Naming Service
• // using JNDI API
• Context initialNamingContext new
  InitialContext()
• initialNamingContext.rebind("HelloServ
  ice", helloRef )
• System.out.println("Hello Server
  Ready...")
• catch (Exception e)
• System.out.println("Trouble " e)
• e.printStackTrace()
  

55
RMI-IIOP Sample Code- Client

• public class HelloClient public static void
  main( String args ) Context ic
  Object objref HelloInterface hi
• try ic new InitialContext()
  // STEP 1 Get the Object reference
  from the Name Service using JNDI call.
  objref ic.lookup("HelloService")
  System.out.println("Client Obtained a ref. to
  Hello server.") // STEP 2 Narrow
  object reference to the concrete type and invoke
  the method. hi (HelloInterface)
  PortableRemoteObject.narrow(
  objref, HelloInterface.class)
  hi.sayHello( " MARS " )
• catch( Exception e )
  System.err.println( "Exception " e "Caught"
  ) e.printStackTrace( )
  return

56
Registry vs. IIOP - interfaceImpl

• public class HelloImpl extends UnicastRemoteObject
  implements HelloInterface

• public class HelloImpl extends PortableRemoteObjec
  t implements HelloInterface

57
Registry vs. IIOP Server Side

• SomeImpl exportedObj new SomeImpl()
• registryURL"rmi//localhost"portNum "/some"
• Naming.rebind(registryURL, exportedObj)
• // using RMI registry

• HelloImpl helloRef new HelloImpl()
• initialNamingContext new InitialContext()
• initialNamingContext.rebind("HelloService",
  helloRef ) // using JNDI

58
Registry vs. IIOP Client Side

• String registryURL "rmi//localhost" portNum
  "/some"
• SomeInterface h (SomeInterface)Naming.lookup
  (registryURL)
• String message h.method1()

• Context ic new InitialContext()
• objref ic.lookup("HelloService")
• hi (HelloInterface) PortableRemoteObject.narrow
  (objref, HelloInterface.class)
• hi.sayHello( " MARS " )

59
Steps for building an RMI application
60
Algorithm for developing the server-side software

• Open a directory for all the files to be
  generated for this application.
• Specify the remote-server interface in
  SomeInterface.java. Compile it until there is no
  more syntax error.
• Implement the interface in SomeImpl.java Compile
  it until there is no more syntax error.
• Use the RMI compiler rmic to process the
  implementation class and generate the stub file
  and skeleton file for the remote object
• unixgt rmic SomeImpl
• The files generated can be found in the
  directory as SomeImpl_Skel.class and
  SomeImpl_Stub.class.
• Steps 3 and 4 must be repeated each time that a
  change is made to the interface implementation.
• 5. Create the object server SomeServer.java.
  Compile it until there is no more syntax error.
• 6. Activate the object server
• unixgt java SomeServer

61
Algorithm for developing the client-side software

• 1. Open a directory for all the files to be
  generated for this application.
• 2. Obtain a copy of the remote interface class
  file. Alternatively, obtain a copy of the source
  file for the remote interface, and compile it
  using javac to generate the interface class
  file.
• Obtain a copy of the stub file for the
  implementation of the interface
• SomeImpl_Stub.class.
• 4. Develop the client program SomeClient.java,
  and compile it to generate the client class.
• 5. Activate the client.
• unixgt java SomeClient

62
Placement of files for a RMI application
63
Testing and Debugging an RMI Application

• 1. Build a template for a minimal RMI program.
  Start with a remote interface with a single
  signature, its implementation using a stub, a
  server program which exports the object, and a
  client program which invokes the remote method.
  Test the template programs on one host until the
  remote method can be made successfully.
• 2. Add one signature at a time to the interface.
  With each addition, modify the client program to
  invoke the added method.
• 3. Fill in the definition of each remote method,
  one at a time. Test and thoroughly debug each
  newly added method before proceeding with the
  next one.
• 4. After all remote methods have been thoroughly
  tested, develop the client application using an
  incremental approach. With each increment, test
  and debug the programs.

64
Comparison of the RMI and the socket APIs

• The remote method invocation API is an efficient
  tool for building network applications. It can
  be used in lieu of the socket API in a network
  application. Some of the tradeoffs between the
  RMI API and the socket API are as follows
• The socket API is closely related to the
  operating system, and hence has less execution
  overhead. For applications which require high
  performance, this may be a consideration.
• The RMI API provides the abstraction which eases
  the task of software development. Programs
  developed with a higher level of abstraction are
  more comprehensible and hence easier to debug.

65
The HelloWorld Sample
66
Diagrams for the Hello application
67
Source files for the Hello application

• HelloInterface.java
• HelloImpl.java
• HelloClient.java
• Demo example
• http//java.sun.com/j2se/1.4.2/docs/guide/rmi/gets
  tart.doc.html

68
A Sample Enterprise Application

• In the illustrated application, the object
  server provides remote methods which allows the
  object clients to look up or update the data in
  an Expense Records database. Programs which are
  clients of the object provide the application or
  business logic for processing the data and the
  presentation logic for the user interface which
  presents the data.

69
To be continued

• The Java RMI facility is rich in features. This
  chapter has presented a very basic subset of
  those features, as an illustration of a
  distributed object system. Some of the more
  interesting advanced features of RMI will be
  presented in the next chapter.

70
Summary - 1

• The distributed object paradigm is at a higher
  level of abstraction than the message-passing
  paradigm.
• Using the paradigm, a process invokes methods of
  a remote object, passing in data as arguments and
  receiving a return value with each call, using
  syntax similar to local method calls.
• In a distributed object system, an object server
  provides a distributed object whose methods can
  be invoked by an object client.

71
Summary - 2

• Each side requires a proxy which interacts with
  the systems runtime support to perform the
  necessary IPC.
• an object registry must be available which allow
  distributed objects to be registered and looked
  up.
• Among the best-known distributed object system
  protocols are the Java Remote Method Invocation
  (RMI), the Distributed Component Object, Model
  (DCOM), the Common Object Request Broker
  Architecture (CORBA) , and the Simple Object
  Access Protocol (SOAP).

72
Summary - 3

• Java RMI is representative of distributed object
  systems.
• The architecture of the Java Remote Method
  Invocation API includes three abstract layers on
  both the client side and the server side.
• The software for a RMI application includes a
  remote interface, server-side software, and
  client-side software.
• What are the tradeoffs between the socket API and
  the Java RMI API?