distributed objects n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Distributed Objects PowerPoint Presentation
Download Presentation
Distributed Objects

Loading in 2 Seconds...

play fullscreen
1 / 72

Distributed Objects - PowerPoint PPT Presentation


  • 182 Views
  • Uploaded on

Distributed Objects. Message Passing vs. Distributed Objects. Message Passing versus Distributed Objects.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Distributed Objects' - chesmu


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
message passing versus distributed objects
Message Passing versus Distributed Objects
  • The message-passing paradigm is a natural model for distributedcomputing, in the sense that it mimics interhuman communications. It is an appropriate paradigm for network services where processes interact with each other through theexchanges of messages.
  • However, the abstraction provided by this paradigm doesnot meet the needs of the complexity of sophisticated network applications.
message passing versus distributed objects 2
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 isdata-oriented. Each message contains data marshalled in a mutually agreed upon format, and isinterpreted 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.
the distributed object paradigm
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 stateor data of the entity: in Java, such data is contained in the instance variables of each object;
    • the operationsof the entity, through which the state of the entity can be accessed or updated.
object oriented programming
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 fouroperations:

  • 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.
object oriented programming1
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

local objects vs distributed objects
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.
the distributed object paradigm1
The Distributed Object Paradigm

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

m essage passing versus distributed objects
Message Passing versus Distributed Objects

Compared to the message-passing paradigm, which is data-oriented, the distributedobjects 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.

the distributed object paradigm 2
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 clientprocessof that object, and the methods of the remoteobject are called remotemethods (as opposed to local methods, or methods belonging to a local object) to the client process.
an archetypal distributed objects system
An Archetypal Distributed Objects System

Server Objects need to be registered in an object registry, e.g., RMI registry.

distributed object system 1
Distributed Object System - 1
  • A distributedobject 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 objectto beregistered.
  • To access a distributed object, a process –an object client – looks up the object registry for a reference[1] to the object. This objectreference 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.

distributed object system 2
Distributed Object System - 2
  • Logically, the object clientmakes a call directly to a remotemethod.
  • In reality, the call is handled by a software component, called a client proxy/stub, which interacts the software on the clienthost that provides the runtimesupport 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.
distributed object system 3
Distributed Object System - 3
  • A similar architecture is required on the serverside, 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 serverproxyinterfaces with the distributedobject 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 marshalleddata for the returned value, is forwarded by the serverproxy to the clientproxy, via the runtime support and network support on both sides.
distributed object systems protocols
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 wellknown 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

remote procedure calls rpc
Remote Procedure Calls (RPC)
  • Remote Method Invocation (RMI) has its origin in a paradigm called Remote Procedure Call (RPC)
  • In the RPC model, a procedurecallis 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.
remote procedure calls rpc 2
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 twoprevalent 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 DistributedComputing Environment (DCE)RPC.
  • Both APIs provide a tool, rpcgen, for transforming remote procedure calls to local procedure calls to the stub.
remote method invocation
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 serverexports a remoteobject 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 remoteobject is declared with a remote interface, a Java interface.
    • The remote interfaceisimplemented by the object server.
    • An objectclient accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations.
object registry
Object Registry
  • The RMI API allows a number of directoryservices to be used[1] for registering a distributed object.
  • We will use a simple directory service called the RMIregistry, rmiregistry, which is provided with the Java Software Development Kit (SDK)[2].
  • The RMIRegistry is a service whose server, when active, runs on the objectserver’shostmachine, by convention and by default on the TCP port1099.

[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 .

the interaction between the stub and the skeleton
The interaction between the stub and the skeleton

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

the api for the java rmi
The API for the Java RMI
  • The RemoteInterface
  • The Server-side Software
    • The RemoteInterfaceImplementation
    • Stub and Skeleton Generations
    • The Object Server
  • The Client-side Software
the remote interface
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 Remoteexception (exceptions handling) that must be specified with each method signature, a remote interface has the same syntax as a regular or localJava interface.
a sample remote interface
A sample remote interface

// file: SomeInterface.java

// to be implemented by a Java RMI server class.

import java.rmi.*

publicinterfaceSomeInterfaceextendsRemote{

// 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 ofinterface

a sample remote interface 2
A sample remote interface - 2
  • The java.rmi.RemoteExceptionmust 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 exceptionis required to becaught in the method caller’s program.
  • Causes of such exceptions include exceptions that may occur during interprocess communications, such as accessfailures and connectionfailures, as well as problems unique to remote method invocations, including errors resulting from the object, the stub, or the skeletonnot being found.
the server side software
The Server-side Software

A serverobject provides the methods of the interface to a distributed object. Each server object must

  • implement each of the remotemethod 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.

the remote interface implementation
The Remote Interface Implementation

A server classimplements the remoteinterface--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 extendsUnicastRemoteObject

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

uml diagram for the someimpl class
UML diagram for the SomeImpl class

inherits from

implements

the object server
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 = newSomeImpl();

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

the object server 2
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(intRMIPortNum)

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

the object server 3
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 obtainingreferences 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 overwriteany reference in the registry bound with the given reference name. If the overwriting is not desirable, there is also a bindmethod.
  • 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.
the object server 4
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.
stub and skeleton generations
Stub and Skeleton Generations
  • In RMI, each distributed object requires a proxy for the objectserverand the objectclient, known as the object’s skeleton and stub respectively.
  • These proxies are generated from the implementation of a remote interface using the RMI compilerrmic.

rmic <class name of the remote interface implementation>

For example:

Unix> rmic SomeImpl

As a result of the compilation, two proxyfiles will be generated, each prefixed with the implementation class name:

SomeImpl_skel.class

SomeImpl_stub.class.

the stub file for the object
The stub file for the object
  • The stub file for the object, as well as the remote interface file, must be shared with each objectclient – 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 clientdynamically throughHPPT.
the rmi registry
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 );

the rmi registry 2
The RMI Registry - 2
  • Alternatively, an RMI registry can be activated by using the rmiregistryutility 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)
the client side software
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

  • lookingup 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.
the client side software 2
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

looking up the remote object
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);

invoking the remote method
Invoking the Remote Method

The remote interface reference can be used to invokeany 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 interfaceimplementationclass or the serverobjectclass . Instead it should be cast as theremoteinterface.
internet inter orb protocol iiop
Internet Inter-ORB Protocol (IIOP)

-----------------------

Application Objects

-----------------------

ORB

-----------------------

IIOP

-----------------------

TCP

-----------------------

IP

-----------------------

Ethernet

-----------------------

Physical Device

-----------------------

rmic with iiop option
RMIC with IIOP option
  • rmic -iiop
    • Causes rmic to generate IIOPstub and tie classes, rather than JRMP (Java Remote Method Protocol)stub and skeleton classes.
    • A stubclass is a local proxyfor a remote object and is used by clients to send calls to a server.
    • Eachremote interface requires a stub class, which implements that remote interface. A client's referenceto a remote object is actually a reference to a stub.
    • Tieclasses are used on the serverside 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

java naming and directory interface
Java Naming and Directory Interface
  • The Java Naming and Directory Interface (JNDI) is an application programming interface (API) that provides naming and directoryfunctionality 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 directoryservices 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 haveattributes. 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

java naming and directory interface1
Java Naming and Directory Interface

From: http://java.sun.com/products/jndi/tutorial/getStarted/overview/index.html

cos naming service 1
COS Naming Service - 1
  • The CORBACOS (Common Object Services) Naming Service provides a tree-likedirectory 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-objectassociation 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

cos naming service 2
COS Naming Service - 2
  • Because a context is like any other object, it can also be bound to a name in a namingcontext.
  • Binding contexts in other contexts creates a naminggraph - a directed graph with nodes and labeled edges where the non-leafnodesarecontexts, and leaf nodes are object references.
  • A naminggraph allows more complexnames 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 compoundname) defines a path in the naming graph to navigate the resolution process.
cos naming service 3
COS Naming Service - 3
  • plans is an object reference
  • Personal is a naming context that contains two objectreferences: calendar and schedule.
  • From: http://java.sun.com/j2se/1.4.2/docs/guide/idl/jidlNaming.html#example1
rmi iiop sample code interfaceimpl
// interface

public interfaceHelloInterface extends java.rmi.Remote { public void sayHello( String from ) throws java.rmi.RemoteException; }

// Interface implementation

public class HelloImpl extends PortableRemoteObjectimplementsHelloInterface {

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(); } }

RMI-IIOP Sample Code- interfaceImpl
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

ContextinitialNamingContext = new InitialContext();

initialNamingContext.rebind("HelloService", helloRef );

System.out.println("Hello Server: Ready...");

} catch (Exception e) {

System.out.println("Trouble: " + e);

e.printStackTrace(); } } }

RMI-IIOP Sample Code- Server
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; } } }

RMI-IIOP Sample Code- Client
registry vs iiop interfaceimpl
Registry vs. IIOP - interfaceImpl
  • public class HelloImpl extendsPortableRemoteObjectimplements HelloInterface { … }
  • public class HelloImpl extendsUnicastRemoteObjectimplements HelloInterface { … }
registry vs iiop server side
Registry vs. IIOP – ServerSide
  • HelloImpl helloRef = new HelloImpl();
  • initialNamingContext = new InitialContext();
  • initialNamingContext.rebind("HelloService", helloRef ); // using JNDI
  • SomeImpl exportedObj = new SomeImpl();
  • registryURL="rmi://localhost:"+portNum+ "/some";
  • Naming.rebind(registryURL, exportedObj);

// using RMI registry

registry vs iiop client side
Registry vs. IIOP – ClientSide
  • 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 " );
algorithm for developing the server side software
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 compilerrmic to process the implementation class and generate the stub file and skeleton file for the remote object:

unix> rmicSomeImpl

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 objectserverSomeServer.java. Compile it until there is no more syntax error.

6. Activate the object server

unix> javaSomeServer

algorithm for developing the client side software
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 classfile. 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.

unix> javaSomeClient

testing and debugging an rmi application
Testing and Debugging an RMI Application

1. Build a template for a minimal RMI program. Start with a remote interface with a singlesignature, 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.

comparison of the rmi and the socket apis
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 highperformance, this may be a consideration.
  • The RMI API provides the abstraction which eases the task of software development. Programs developed with a higherlevel of abstraction are more comprehensible and hence easier to debug.
source files for the hello application
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/getstart.doc.html
a sample enterprise application
A Sample Enterprise Application

In the illustrated application, the object server provides remotemethods 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.

to be continued
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.

summary 1
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.
summary 2
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).
summary 3
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?