distributed objects and advanced remote method invocations

6 Maart 2006 ISS 2006 1

Distributed Objectsand

Advanced Remote Method Invocations

René de Vries

Based on the slides by M.L. Liu and Marko van Eekelen

6 Maart 2006 ISS 2006 2

Overview (Distributed Objects)

Message Passing vs. Distributed Objects The Distributed Objects Paradigm Remote Procedure Call vs Remote Method

Invocation Java RMI

The Java RMI Architecture The Object Registry Stubs and Skeletons

Steps for building an RMI application

6 Maart 2006 ISS 2006 3

Message Passingvs. Distributed Objects

6 Maart 2006 ISS 2006 4

The Message Passing Paradigm

Natural model for distributed computing. mimics interhuman communications.

Processes are 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 marshalled data, and is interpreted as a

request or response according to the protocol. 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.

6 Maart 2006 ISS 2006 5

The Distributed Objects Paradigm

The distributed object paradigm is a paradigm that provides abstractions beyond those of the message-passing model. It is based on objects that exist in a distributed system.

In object-oriented programming, supported by an object-oriented programming language such as Java, 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 Maart 2006 ISS 2006 6

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.

6 Maart 2006 ISS 2006 7

The Distributed Objects Paradigm-2

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

o bje ct s ta te da ta it e m

o bje ct o pe ra t io n

H o s t A H o s t B

clie n t pro ce s sm e th o d ca ll

a dis t r ibu te d o bje ct

6 Maart 2006 ISS 2006 8

The Distributed Objects Paradigm - 3

A process running in host A makes a method call to a distributed object residing on host B, passing with the call data for the parameters, if any.

The method call invokes an action performed by the method on host B, and a return 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 object are called remote methods (as opposed to local methods, or methods belonging to a local object) to the client process.

6 Maart 2006 ISS 2006 9

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

6 Maart 2006 ISS 2006 10

The Distributed Objects Paradigm

6 Maart 2006 ISS 2006 11

An Archetypal Distributed Objects System

o bje ct c lie n t o bje ct s e rv e r

clie n tpro x y

s e rv e rpro x y

ru n t im es u ppo rt

n e two rks u ppo rt


ph y s ica l da ta pa th

lo g ica l da ta pa th

o bje ctre g is t ry


6 Maart 2006 ISS 2006 12

Distributed Object System

A distributed object is provided, or exported, by a process, here called the 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 reference is 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.

6 Maart 2006 ISS 2006 13

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, which interacts which 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.

6 Maart 2006 ISS 2006 14

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.

The server proxy interfaces with the distributed object to invoke the method call locally, 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 return value, is forwarded by the server proxy to the client proxy, via the runtime support and network support on both sides.

6 Maart 2006 ISS 2006 15



clie n tpro x y

s e rv e rpro x y








6 Maart 2006 ISS 2006 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,~.NET and its predecessor, the Distributed Component

Object Model (DCOM)~mechanisms that support the Simple Object Access

Protocol (SOAP).

Of these, the most straightforward is the Java RMI

6 Maart 2006 ISS 2006 17

From Remote Procedure Call to Remote Method Invocation

6 Maart 2006 ISS 2006 18

Remote Procedure Calls (RPC) Remote Method Invocation has its origin in a paradigm called

Remote Procedure Call In the remote procedure call 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 return value, if any, is transmitted from the callee to the caller.

p r o c 1 ( a r g 1 , a r g 2 )

Pro ce s s APro ce s s B

a r e m o t e p r o c e d u r e

retu rn va lu e

e x e c u t i o n f l o w

6 Maart 2006 ISS 2006 19

Local Procedure Call and Remote Procedure Call

p r o c 1

e x e c u t i o n f l o w

p r o c 2

h o s t A

A l o c a l p r o c e d u r e c a l l

h o s t Ah o s t B

A r e m o te p r o c e d u r e c a l l( t h e r e t u r n e x e c u t i o n p a th i s n o t s h o w n )

p r o c 1p r o c 2

p r o x yp r o x y

1 . p r o c 1 o n h o s t A m a k e s a c a l l t o p r o c 2 o n h o s t B .2 . Th e r u n t i m e s u p p o r t m a p s t h e c a l l t o a c a l l t o t h e p r o x y o n h o s t A .3 . Th e p r o x y m a r s h a l l s t h e d a t a a n d m a k e s a n IP C c a l l t o a p r o x y o n h o s t B .

7 . Th e p r o x y r e c e i ve d t h e r e t u r n va l u e , u n m a r s h a l l s t h e d a t a , a n d fo r w a r d s th e r e tu r n va l u e t o p r o c 1 , w h i c h r e s u m e s i t s e x e c u t i o n f l o w .

4 . Th e p r o x y o n h o s t Bu n m a r s h a l l s t h e d a t a

r e c e i ve d a n d i s s u e s a c a l l t o p r o c 2 .5 . Th e c o d e i n p r o c 2 i s e x e c u t e d a n d r e t u r n s t o t h e p r o x y o n h o s t B .6 . Th e p r o x y m a r s h a l l s t h e r e t u r n va l u e a n d m a k e s a n IP C c a l l t o t h e p r o x y o n h o s t A .

6 Maart 2006 ISS 2006 20

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

6 Maart 2006 ISS 2006 21

Java Remote Method Invocation

6 Maart 2006 ISS 2006 22

Remote Method Invocation

Remote Method Invocation (RMI) is an object-oriented implementation of the Remote Procedure Call 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. The object provides remote methods, which can be invoked in client programs.

Syntactically: A remote object is declared with a remote interface, an

extension of the 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.

6 Maart 2006 ISS 2006 23

The Java RMI Architecture

s tu b

re m o te re fe re n ce la y e r

tra n s po rt la y e r

s k e le to n

re m o te re fe re n ce la y e r

tra n s po rt la y e r



s u p p o r ts th e in ter f ac e w ithth e ap p lic a tio n p ro g r am

m ap s th e p la tf o r m - in d ep en d en t s tu b /s k ele to nlay er to th e p la tf o rm - d ep en d en t tr an s p o r tlay er ; c ar r ies o u t r em o te r e f er en c e p r o to c o ls

s e ts u p , m ain ta in s , an d s h u ts d o w nc o n n ec tio n s ; an d c ar r ies o u t th etr an s p o r t p ro to c o l

o bje ctclie n t

o bje cts e rv e r

D ire cto ry s e rv ice

6 Maart 2006 ISS 2006 24



clie n tpro x y

s e rv e rpro x y








6 Maart 2006 ISS 2006 25

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 .

6 Maart 2006 ISS 2006 26

The interaction between the stub and the skeleton

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

s k e le to n

m a rs h a l pa ra m e te rs ;s e n d R e qu e s t

u n m a rs h a l pa ra m e te rsI n v o k e m e th o d

R e m o teM e th o d

e x e cu te co dea n d re tu rn av a lu e

re ce iv e re tu rn v a lu em a rs h a l re plys e n d re ply

u n m a rs h a ll re ply ;re tu rn v a lu e

t im e

(ba s e d o n h t tp: // ja v a . s u n .co m .m a rk e t in g /co lla te ra l/ja v a rim .h tm l)

s tu b

6 Maart 2006 ISS 2006 27

Steps for building an RMI application

6 Maart 2006 ISS 2006 28

Algorithm for developing the server-side software

1. Study chapters 7.7 and 7.8 of the book carefully.2. Open a directory for all the files to be generated for this application. 3. Specify the remote-server interface in SomeInterface.java. Compile

it until there is no more syntax error.4. Implement the interface in SomeImpl.java Compile it until there is no

more syntax error.5. Use the RMI compiler rmic to process the implementation class and

generate the stub file and skelton file for the remote object: 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.

6. Create the object server program SomeServer.java. Compile it until there is no more syntax error.

7. Activate the object server java SomeServer

6 Maart 2006 ISS 2006 29

Algorithm for developing the client-side software

1. Study chapters 7.7 and 7.8 of the book carefully.2. Open a directory for all the files to be generated for this

application.3. 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.

4. Obtain a copy of the stub file for the implementation of the interface:

SomeImpl_Stub.class.

5. Develop the client program SomeClient.java, and compile it to generate the client class.

6. Activate the client. java SomeClient

6 Maart 2006 ISS 2006 30

Placement of files for a RMI application

S o m e C lie n t .c la s s

O bje ct C lie n t h o s t O bje ct S e rv e r h o s t

o bje ct s e rv e r dire cto ry

S o m e I n te rfa ce .c la s s

S o m e I n te rfa ce .c la s s

S o m e I m pl.c la s s

S o m e S e rv e r.cla s s

S o m e I m pl_ S k e l.c la s sS o m e I m pl_ S tu b.cla s s

o bje ct c lie n t dire cto ry

Error in Figure 7.17 of the book !

6 Maart 2006 ISS 2006 31

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.

6 Maart 2006 ISS 2006 32

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.

6 Maart 2006 ISS 2006 33

A Sample Enterprise ApplicationIn 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.

S er v er

C lien t

C lien t

C lien t

E x p en s e R ec o r d sJ D BC

R M I

R M I

R M I

A n Ex pe n s e R e po rt in g S y s te m , f r o m h ttp :/ / jav a . s u n .c o m

6 Maart 2006 ISS 2006 34

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 2nd half of this lecture.

6 Maart 2006 ISS 2006 35

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.

6 Maart 2006 ISS 2006 36

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 allows 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), .NET, the Common Object Request Broker Architecture (CORBA) , and the Simple Object Access Protocol (SOAP).

6 Maart 2006 ISS 2006 37

Summary - 3

Java RMI is a 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.

There are tradeoffs between the socket API and the Java RMI API.

6 Maart 2006 ISS 2006 38

BREAK

6 Maart 2006 ISS 2006 39

Advanced Remote Method Invocations

6 Maart 2006 ISS 2006 40

RMI – Advanced topics

The Java RMI API has a rich collection of features. We will look at some of RMI’s more interesting

advanced features, namely: stub downloading security manager client callback.

Although these features are not inherent to the distributed object paradigm, they are helpful mechanisms and can be useful to application developers.

6 Maart 2006 ISS 2006 41

The Java RMI Architecture

C lien t S er v er

s tu b

r em o te r e f er en c e lay er

tr an s p o r t lay er

s k e le to n

r em o te r e f er en c e lay er

tr an s p o r t lay er

l;o g ic a l d a ta p a th

p h y s ic a l d a ta p a th

s u p p o r ts th e in te r f ac e w ithth e ap p lic a tio n p r o g r am

m ap s th e p la tf o r m - in d ep en d en t s tu b /s k e le to nlay er to th e p la tf o r m - d ep en d en t tr an s p o r tlay er ; c a r r ies o u t r em o te r e f e r en c e p r o to c o ls

s e ts u p , m ain ta in s , an d s h u ts d o w nc o n n ec tio n s ; an d c ar r ies o u t th etr an s p o r t p r o to c o l

6 Maart 2006 ISS 2006 42

Java RMI Client Server Interaction

C lie n t h o s tS e rv e r h o s t

R M I r eg is tr y

S o m eS er v er . c las s

S o m eI n ter f ac e _ s tu b .c las s

S o m eI n ter f ac e _ s k e l. c las s

C lien t. c las s

S o m eI n ter f ac e _ s tu b .c las s

12

3

4

1 . C lie n t lo o k s u p th e in te rfa ce o bje ct in th e R M I re g is t ry o n th e s e rv e r h o s t .2 . Th e R M I R e g is try re tu rn s a re m o te re fe re n ce to th e in te rfa ce o bje ct .3 . I f th e in te rfa ce o bje ct 's s tu b is n o t o n th e c lie n t h o s t a n d if it is s o a rra n g e d by th e s e rv e r, th e s tu b is do wn lo a de d fro m a n H TTP s e rv e r.4 . V ia th e s e rv e r s tu b, th e clie n t pro ce s s in te ra ct s with th e s k e le to n o f th e in te rfa ce o bje ct t o a cce s s th e m e th o ds in th e s e rv e r o bje ct .

H TTP h o s t

X

6 Maart 2006 ISS 2006 43

RMI Stub Downloading

RMI is designed to allow stubs to be made available to the client dynamically. Doing so allows changes to be made in the remote methods without affecting the client program.

The stub can be filed with an web server and be downloaded using HTTP.

Security measures are needed to prevent both the client side and the server side:

A java security policy file needs to be set on the server host and also on the client host.

A Java Security Manager should be instantiated in both the client and server programs.

6 Maart 2006 ISS 2006 44

Stub downloading

If the stub is to be downloaded from a remote server, transfer the stub class to the appropriate directory on that server, e.g., www.csc.calpoly.edu/~mliu/www, and make sure that the access permission to the file is set.

When activating the server, specify command options:

java -D java.r m i .s e r ve .c o de bas e = < U R L > / \ -D java.r m i .s e r ve r .ho s tnam e = < s e r ve r ho s t nam e > \ -D java.s e c ur i ty.po l i c y= < ful l d i r e c to r y path to java po l i c y fi l e >w he r e < U R L > i s the U R L fo r the s tub c l as s , e .g ., h t tp: / / w w w .c s c .c al po l y.e du /~ m l i u /c l as s < s e r ve r ho s t nam e > i s the nam e o f the ho s t o n w hi c h the s e r ve r r uns ,and < ful l d i r e c to r y path to java po l i c y fi l e > s pe c i fi e s w he r e the s e c ur i ty po l i c y fi l e fo r th i s appl i c at i o n i s to be fo und, e .g ., java.s e c ur i ty i f yo u have a fi l e by that nam e i n the d i r e c to r y w he r e the s e r ve r c l as s i s .

6 Maart 2006 ISS 2006 45

The java.policy file

The RMI security manager does not permit network access. Exceptions can be made via the specification in a java.policy file.grant { // permits socket access to all common TCP ports, including the default

// RMI registry port (1099) – need for both the client and the server. permission java.net.SocketPermission "*:1024-65535",

"connect,accept,resolve"; // permits socket access to port 80, the default HTTP port – needed // by client to contact an HTTP server for stub downloading permission java.net.SocketPermission "*:80", "connect";

}; This file can be filed in the same directory as the server class file. When activating the client, a java.policy file also should be specified: java -Djava.security.policy=java.policy SomeClient See http://java.sun.com/products/jdk/1.2/docs/guide/security/PolicyFiles.html and http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html

6 Maart 2006 ISS 2006 46

File Placements

java.policy

SomeClient.class

java.policy

SomeServer.class

SomeInterface_ stub.class

SomeInterface.Skeleton.class

SomeInterface _stub.class

Client host

client directory

Server host

server directory

HTTP Server

6 Maart 2006 ISS 2006 47

RMI Security Manager

Since RMI involves access to/from a foreign host, and possibly object downloading, it is important for both the server and the client to protect its system from malicious access.

The RMISecurityManager is a class provided Java, and can be instantiated in both the client and the server for limiting access privileges.

You can write your own security manager, if so desired. try {

System.setSecurityManager(new

RMISecurityManager( ));

}

catch { …}

6 Maart 2006 ISS 2006 48

Algorithm for building an RMI Application

Server side:1. Open a directory for all the files to be generated for this application.

2. Specify the remote-server interface, and compile it to generate the interface class file.

3. Build the remote server class by implementing the interface, and compile it using javac.

4. Use rmic to process the server class to generate a stub.class file and a skelton.class file: rmic SomeServer

5. If stub downloading is desired, copy the stub file to an appropriate directory on the HTTP host.

6. Activate the RMIRegistry, if it has not already been activated.

7. Set up a java.policy file.

8. Activate the server, specifying (i) the codebase if stub downloading is desired, (ii) the server host name, and (iii) the security policy file.

6 Maart 2006 ISS 2006 49

Algorithm for building an RMI Application

Client side:1. Open a directory for all the files to be generated for this

application.2. Implement the client program or applet, and compile it to

generate the client class.3. If stub downloading is not in effect, copy the server

interface stub class file by hand.4. Set up a java.policy file.5. Activate the client, specifying (i) the server host name,

and (ii) the security policy file.

6 Maart 2006 ISS 2006 50

RMI Callbacks

6 Maart 2006 ISS 2006 51

Introduction

In the client server model, the server is passive: the IPC is initiated by the client; the server waits for the arrival of requests and provides responses.

Some applications require the server to initiate communication upon certain events. Examples applications are:

monitoring games auctioning voting/polling chat-room message/bulletin board groupware

6 Maart 2006 ISS 2006 52

Polling vs. Callback

In the absence of callback, a client will have to poll a passive server repeatedly if it needs to be notified that an event has occurred at the server end.

S e rv e r

C lie n t

...

P o lling

S e rv e r

C lie n t

C a llba c k

A clie n t is s u e s a re qu e s t to th es e rv e r re pe a te dly u n t il th ede s ire d re s po n s e is o bta in e d.

A clie n t re g is te rs it s e lf with th es e rv e r, a n d wa it u n t il th e s e rv e rca lls ba ck .

a re m o te m e th o d ca ll

6 Maart 2006 ISS 2006 53

Two-way communications

Some applications require that both sides may initiate IPC. Using sockets, duplex communication can be achieved by using two

sockets on either side. With connection-oriented sockets, each side acts as both a client and a

server.

r eq u es tr es p o n s e

r eq u es t

r es p o n s e

Pro ce s s 1Pro ce s s 1

6 Maart 2006 ISS 2006 54

RMI Callbacks

A callback client registers itself with an RMI server. The server makes a callback to each registered client upon the

occurrence of a certain event.

T h e c a llb ac k lis t

C 1

C 2

C 3

C 4

C 5

c allb ac k

S e rv e rC lie n ts

R M I c a lls

6 Maart 2006 ISS 2006 55

Callback Client-Server Interactions

C lie n t h o s tS e rv e r h o s t

R M I r eg is tr y

S o m eS erv er . c las s

S o m eIn ter f ac e_ s tu b .c las s

S o m eIn ter f ac e_ s k el. c las s

C lien t. c las s12

1 . C lie n t lo o k s u p th e in te rfa ce o bje ct in th e R M I re g is try o n th e s e rv e r h o s t .2 . Th e R M I R e g is try re tu rn s a re m o te re fe re n ce to th e in te rfa ce o bje ct .3 . V ia th e s e rv e r s tu b, th e clie n t pro ce s s in v o k e s a re m o te m e th o d to re g is te r it s e lf fo r ca llba ck , pa s s in g a re m o te re fe re n ce to it s e lf to th e s e rv e r. Th e s e rv e r s a v e s th e re fe re n ce in it s ca llba ck lis t .4 . V ia th e s e rv e r s tu b, th e clie n t pro ce s s in te ra ct s with th e s k e le to n o f th e in te rfa ce o bje ct to a cce s s th e m e th o ds in th e in te rfa ce o bje ct .5 . W h e n th e a n t icipa te d e v e n t ta k e s pla ce , th e s e rv e r m a k e s a ca llba ck to e a ch re g is te re d c lie n t v ia th e ca llba ck in te rfa ce s tu b o n th e s e rv e r s ide a n d th e ca llba ck in te rfa ce s k e le to n o n th e c lie n t s ide .

X

C allb ac k In ter f ac e_ s k el. c las s

C allb ac k In ter f ac e_ s tu b .c las s5

3 ,4

6 Maart 2006 ISS 2006 56

Callback application files

C lie n t .c la s s

C l i e n tIn te rface .cl a s s

S e rve rIn te rface .cl as s

C lie n t I m pl.cla s s

S e rve rIm pl _S tu b.cl a s s

C l i e n tIm pl _s k e l .cl as s

O bje ct c lie n t h o s t

o bje ct c lie n t dire cto ry

S e rv e r.cla s s

S e rve rIn te rface .cl as s

C l i e n tIn te rface .cl a s s

S e rv e rI m pl.c la s s

C l i e n tIm pl _S tu b.cl a s s

S e rve rIm pl _s k e l .cl as s

O bje ct s e rv e r h o s t

o bje ct s e rv e r dire cto ry

6 Maart 2006 ISS 2006 57

RMI Callback file placements

java.policy

SomeClient.class

java.policy

SomeServer.class

SomeInterface_stub.class

SomeInterface.Skeleton.class

SomeInterface_stub.class

Client host

client directory

Server host

server directory

HTTP Server

CallbackInterface_stub.class

CallbackInterface_skel.class

6 Maart 2006 ISS 2006 58

RMI Callback Interface

The server provides a remote method which allows a client to register itself for callbacks.

A Remote interface for the callback is needed, in addition to the server-side interface.

The interface specifies a method for accepting a callback from the server.

The client program is a subclass of RemoteObject and implements the callback interface, including the callback method.

The client registers itself for callback in its main method. The server invokes the client’s remote method upon the

occurrence of the anticipated event.

6 Maart 2006 ISS 2006 59

Algorithm for building an RMI Callback Application

Server side:1. Open a directory for all the files to be generated for this application.2. Specify the remote-server interface, and compile it to generate the interface class

file.3. Build the remote server class by implementing the interface, and compile it using

javac.4. Use rmic to process the server class to generate a stub.class file and a

skeleton.class file: rmic SomeServer5. If stub downloading is desired, copy the stub file to an appropriate directory on the

HTTP host.6. Activate the RMIRegistry, if it has not already been activated.7. Set up a java.policy file.8. Activate the server, specifying (i) the codebase if stub downloading is desired, (ii)

the server host name, and (iii) the security policy file.9. Obtain the CallbackInterface. Compile it with javac, then use rmic to generate the

stub file for the callback.

6 Maart 2006 ISS 2006 60

Algorithm for building an RMI Callback Application

Client side:1. Open a directory for all the files to be generated for

this application.2. Implement the client program or applet, and compile

it to generate the client class.3. If stub downloading is not in effect, copy the server

interface stub class file by hand.4. Implement the callback interface. Compile it using

javac, then using rmic to generate a stub class and a skeleton class for it.

5. Set up a java.policy file.6. Activate the client, specifying (i) the server host

name, and (ii) the security policy file.

6 Maart 2006 ISS 2006 61

Summary-1

Stub downloading allows a stub class to be loaded to an object client at runtime, thereby allowing a remote object’s implementation to be modified and its stub class regenerated without affecting the software on the client host.

A security manager oversees access restrictions specified in a Java security policy file, which can be a system-wide policy file, or a policy file applied to an individual application only.

For security protection, the use of security managers is recommended in all RMI applications, regardless of whether stub downloading is involved.

6 Maart 2006 ISS 2006 62

Summary-2

Client callback: Client callback is useful for an application where

the clients desire to be notified by the server of the occurrence of some event.

Client callback allows an object server to make remote method call to a client via a reference to a client remote interface.

6 Maart 2006 ISS 2006 63

Summary-3

Client callback: To provide client callback, the client-side software

supplies a remote interface, instantiate an object which implements the interface, passes a reference to the object to the server via a remote method call

to the server. The object server:

collects these client references in a data structure. when the awaited event occurs, the object server invokes the callback

method (defined in the client remote interface) to pass data to the client. Two sets of stub-skeletons are needed: one for the server remote interface, the other one for the client remote interface.

Two sets of stub-skeletons are needed: one for the server remote interface, the other one for the client remote interface.

6 Maart 2006 ISS 2006 64

Self study exercises

Chapter 7 Exercises 1,2,3 and 4

Chapter 8 Exercises 1 and 4

distributed objects and advanced remote method invocations

Documents