Transcript Distributed Object

Distributed Objects
4/13/2016
1
Message Passing vs. Distributed
Objects
4/13/2016
2
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/13/2016
3
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.
4/13/2016
4
The distributed object paradigm


The distributed object paradigm is a paradigm that
provides abstractions beyond those of the messagepassing 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.
4/13/2016
5
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 sender’s address, and the
sender’s 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 sender’s
address to be retrieved.
 a getPort method, which allows the sender’s port to be
retrieved.
4/13/2016
6
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
4/13/2016
7
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.
4/13/2016
8
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.
Host A
Host B
client process
method call
object state data item
object operation
4/13/2016
a distributed object
9
Message Passing versus Distributed Objects
Compared to the message-passing
paradigm, which is data-oriented, the
distributed objects paradigm is actionoriented: 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 distributedobject paradigm is more natural to objectoriented software development.
4/13/2016
10
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.
4/13/2016
11
The Distributed Objects
Paradigm
4/13/2016
12
An Archetypal Distributed Objects System
object
registry
object client
object server
client
proxy
server
proxy
runtime
support
runtime
support
network
support
network
support
physical data path
logical data path
Server Objects need to be registered in an object registry, e.g., RMI registry.
4/13/2016
13
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 reference[1]
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.
4/13/2016
14
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.
4/13/2016
15
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.
4/13/2016
16
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
4/13/2016
17
Java Remote Method Invocation
4/13/2016
18
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.
4/13/2016
19
The Java RMI Architecture
Directory service
object
client
object
server
stub
skeleton
supports the interface with
the application program
maps the platform-independent stub/skeleton
layer to the platform-dependent transport
layer; carries out remote reference protocols
remote reference layer
remote reference layer
transport layer
transport layer
sets up, maintains, and shuts down
connections; and carries out the
transport protocol
logical data path
4/13/2016
physical data path
20
Object Registry



The RMI API allows a number of directory services to be
used[1] 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 server’s 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 .
4/13/2016
21
The interaction between the stub and the
skeleton
A
time-event diagram describing the
interaction between the stub and the
skeleton:
stub
skeleton
time
Remote
Method
marshal parameters;
send Request
unmarshal parameters
Invoke method
receive return value
marshal reply
send reply
execute code
and return a
value
unmarshall reply;
return value
4/13/2016
(based on http://java.sun.com.marketing/collateral/javarim.html)
22
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
4/13/2016
23
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.
4/13/2016
24
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
4/13/2016
25
A sample remote interface - 2



The java.rmi.RemoteException must be listed in the
throw clause of each method’s 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
caller’s 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.
4/13/2016
26
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.
4/13/2016
27
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
4/13/2016
28
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
4/13/2016
29
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(RMIPortNum);
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.createRegistry(RMIPortNum);
System.out.println(
"RMI registry created at port " + RMIPortNum);
} } // end startRegistry
4/13/2016
30
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://<host name>:<port number>/<reference name>
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.
4/13/2016
31
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.
4/13/2016
32
Stub and Skeleton Generations


In RMI, each distributed object requires a proxy for the
object server and the object client, known as the object’s
skeleton and stub respectively.
These proxies are generated from the implementation of a
remote interface using the RMI compiler rmic.
rmic <class name of the remote interface implementation>
For example:
Unix> 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.
4/13/2016
33
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.
4/13/2016
34
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.LocateRegistry;
…
LocateRegistry.createRegistry ( 1099 );
…
4/13/2016
35
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:
unix> rmiregistry <port number>

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)
4/13/2016
36
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.
4/13/2016
37
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
4/13/2016
38
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);
4/13/2016
39
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.
4/13/2016
40
Internet Inter-ORB Protocol (IIOP)
----------------------Application Objects
----------------------ORB
----------------------IIOP
----------------------TCP
----------------------IP
----------------------Ethernet
----------------------Physical Device
-----------------------
4/13/2016
41
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:
_<implementationName>_stub.class
_<interfaceName>_tie.class
4/13/2016
42
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
4/13/2016
43
Java Naming and Directory Interface
From: http://java.sun.com/products/jndi/tutorial/getStarted/overview/index.html
4/13/2016
44
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/idl/jidlNaming.html#example1
4/13/2016
45
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.
4/13/2016
46
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/idl/ji
dlNaming.html#example1
4/13/2016
47
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 PortableRemoteObject
implements HelloInterface {
public HelloImpl() throws java.rmi.RemoteException {
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(); } }
4/13/2016
48
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("HelloService", helloRef );
System.out.println("Hello Server: Ready...");
} catch (Exception e) {
System.out.println("Trouble: " + e);
e.printStackTrace();
}
} }
4/13/2016
49
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;
}}}
4/13/2016
50
Registry vs. IIOP - interfaceImpl

public class HelloImpl extends
UnicastRemoteObject implements
HelloInterface { … }

public class HelloImpl extends
PortableRemoteObject implements
HelloInterface { … }
4/13/2016
51
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
4/13/2016
52
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 " );
4/13/2016
53
Steps for building an RMI application
4/13/2016
54
Algorithm for developing the server-side software
1.
2.
3.
4.
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:
unix> rmic SomeImpl
The files generated can be found in the directory as SomeImpl_Skel.class and
SomeImpl_Stub.class.
5.
6.
Steps 3 and 4 must be repeated each time that a change is made to the
interface implementation.
Create the object server SomeServer.java. Compile it until there is no
more syntax error.
Activate the object server
unix> java SomeServer
4/13/2016
55
Algorithm for developing the client-side software
1. Open a directory for all the files to be generated for this
2.
3.
application.
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
5.
compile it to generate the client class.
Activate the client.
unix>
4/13/2016
java SomeClient
56
Placement of files for a RMI application
Object Client host
Object Server host
object server directory
object client directory
SomeInterface.class
SomeClient.class
SomeImpl_Stub.class
4/13/2016
SomeInterface.class
SomeServer.class
SomeImpl.class
SomeImpl_Skel.class
57
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.
4/13/2016
58
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.
4/13/2016
59
The HelloWorld Sample
4/13/2016
60
Diagrams for the Hello application
HelloInterface
UnicastRemoteObject
HelloServer
sayHello( )
HelloImpl
HelloClient
listRegistry( )
startRegistry( )
UML di agram
client
registry
server
rebind( )
look up( )
sayHello( )
4/13/2016
sequence di agram
61
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/ge
tstart.doc.html
4/13/2016
62
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.
Client
Client
RMI
RMI
RMI
Client
Server
JDBC
4/13/2016
Expense Records
An Expense Reporting System, from http://java.sun.com
63
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.
4/13/2016
64
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.
4/13/2016
65
Summary - 2



Each side requires a proxy which interacts with the
system’s 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).
4/13/2016
66
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 clientside software.
What are the tradeoffs between the socket API and
the Java RMI API?
4/13/2016
67