Transcript Document

Distributed Objects
and
Advanced Remote Method
Invocations
René de Vries
Based on the slides by M.L. Liu and Marko van Eekelen
6 Maart 2006
ISS 2006
1
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
2
Message Passing
vs. Distributed Objects
6 Maart 2006
ISS 2006
3
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
4
The Distributed Objects Paradigm


The distributed object paradigm is a paradigm that
provides abstractions beyond those of the messagepassing model. It is based on objects that exist in a
distributed system.
In object-oriented programming, supported by an objectoriented 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
5
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
6
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.
Host A
Host B
client process
method call
object state data item
object operation
a distributed object
6 Maart 2006
ISS 2006
7
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
8
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, 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.
6 Maart 2006
ISS 2006
9
The Distributed Objects
Paradigm
6 Maart 2006
ISS 2006
10
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
6 Maart 2006
ISS 2006
11
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
12
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
13
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
14
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
6 Maart 2006
ISS 2006
15
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
16
From Remote Procedure Call
to Remote Method Invocation
6 Maart 2006
ISS 2006
17
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.
Process A
Process B
proc1(arg1, arg2)
return value
a re mote proce dure
e xe cution flow
6 Maart 2006
ISS 2006
18
Local Procedure Call and Remote Procedure Call
host A
proc1
execution flow
proc2
A local procedure call
host B
host A
1. proc1 on host A makes a call
to proc 2 on host B.
2. The runtime support maps
the call to a call to the proxy
on host A.
3. The proxy marshalls the data
and makes an IPC call to a
proxy on host B.
7. The proxy received the return
value, unmarshalls the data,
and forwards the return value
to proc1, which resumes its
execution flow.
proc1
proc2
proxy
proxy
4. The proxy on host B
unmarshalls the data
received and issues a
call to proc2.
5. The code in proc2 is
executed and returns
to the proxy on host B.
6. The proxy marshalls
the return value and
makes an IPC call to
the proxy on host A.
A remote procedure call
(the return execution path is not shown)
6 Maart 2006
ISS 2006
19
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
20
Java Remote Method Invocation
6 Maart 2006
ISS 2006
21
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
22
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
physical data path
6 Maart 2006
ISS 2006
23
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
6 Maart 2006
ISS 2006
24
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
25
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
(based on http://java.sun.com.marketing/collateral/javarim.html)
6 Maart 2006
ISS 2006
26
Steps for building an RMI application
6 Maart 2006
ISS 2006
27
Algorithm for developing the server-side software
1.
2.
3.
4.
5.
Study chapters 7.7 and 7.8 of the book carefully.
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 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.
6.
7.
Steps 3 and 4 must be repeated each time that a change is made to
the interface implementation.
Create the object server program SomeServer.java. Compile it until
there is no more syntax error.
Activate the object server
java
SomeServer
6 Maart 2006
ISS 2006
28
Algorithm for developing the client-side software
1.
2.
3.
4.
Study chapters 7.7 and 7.8 of the book carefully.
Open a directory for all the files to be generated for this
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.
5.
6.
Develop the client program SomeClient.java, and
compile it to generate the client class.
Activate the client.
java SomeClient
6 Maart 2006
ISS 2006
29
Placement of files for a RMI application
Object Client host
Object Server host
object server directory
object client directory
SomeInterface.class
SomeInterface.class
SomeServer.class
SomeImpl.class
SomeClient.class
SomeImpl_Skel.class
SomeImpl_Stub.class
Error in Figure 7.17 of the book !
6 Maart 2006
ISS 2006
30
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
31
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
32
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
Expense Records
An Expense Reporting System, from http://java.sun.com
6 Maart 2006
ISS 2006
33
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
34
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
35
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
36
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 clientside software.
There are tradeoffs between the socket API and the
Java RMI API.
6 Maart 2006
ISS 2006
37

BREAK
6 Maart 2006
ISS 2006
38
Advanced Remote Method
Invocations
6 Maart 2006
ISS 2006
39
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
40
The Java RMI Architecture
Client
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
l;ogical data path
physical data path
6 Maart 2006
ISS 2006
41
Java RMI Client Server Interaction
Server host
Client host
Client.class
1
2
3
RMI registry
HTTP host
SomeInterface_stub.class
SomeInterface_stub.class
4
X
SomeInterface_skel.class
SomeServer.class
1. Client looks up the interface object in the RMIregistry on the server host.
2. The RMIRegistry returns a remote reference to the interface object.
3. If the interface object's stub is not on the client host and if it is so arranged by the
server, the stub is downloaded from an HTTP server.
4. Via the server stub, the client process interacts with the skeleton of the interface object
to access the methods in the server object.
6 Maart 2006
ISS 2006
42
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
43
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 -Djava.rmi.serve.codebase
= <URL>/
\
-Djava.rmi.server.hostname=<server host name> \
-Djava.security.policy=<full directory path to java policy file>
where <URL> is the URL for the stub class, e.g.,
http://www.csc.calpoly.edu/~mliu/class
<server host name> is the name of the host on which
the server runs,
and <full directory path to java policy file> specifies where the
security policy file for this application is to be found,
e.g., java.security if you have a file by that name in the
directory where the server class is.
6 Maart 2006
ISS 2006
44
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
45
File Placements
Client host
Server host
client directory
server directory
SomeClient.class
SomeServer.class
SomeInterface _stub.class
SomeInterface.Skeleton.class
java.policy
java.policy
HTTP Server
SomeInterface_ stub.class
6 Maart 2006
ISS 2006
46
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
47
Algorithm for building an RMI Application
Server side:
1.
2.
3.
4.
5.
6.
7.
8.
Open a directory for all the files to be generated for this application.
Specify the remote-server interface, and compile it to generate the
interface class file.
Build the remote server class by implementing the interface, and
compile it using javac.
Use rmic to process the server class to generate a stub.class file and
a skelton.class file: rmic SomeServer
If stub downloading is desired, copy the stub file to an appropriate
directory on the HTTP host.
Activate the RMIRegistry, if it has not already been activated.
Set up a java.policy file.
Activate the server, specifying (i) the codebase if stub downloading
is desired, (ii) the server host name, and (iii) the security policy file.
6 Maart 2006
ISS 2006
48
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
49
RMI Callbacks
6 Maart 2006
ISS 2006
50
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:







6 Maart 2006
monitoring
games
auctioning
voting/polling
chat-room
message/bulletin board
groupware
ISS 2006
51
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.
Polling
Callback
Server
Server
...
Client
Client
A client issues a request to the
server repeatedly until the
desired response is obtained.
A client registers itself with the
server, and wait until the server
calls back.
a remote method call
6 Maart 2006
ISS 2006
52
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.
Process 1
Process 1
request
response
request
response
6 Maart 2006
ISS 2006
53
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.
Server
Clients
C1
The callback list
C2
C3
RMI calls
callback
C4
C5
6 Maart 2006
ISS 2006
54
Callback Client-Server Interactions
Server host
Client host
Client.class
1
2
RMI registry
SomeInterface_stub.class
3,4
SomeInterface_skel.class
X
SomeServer.class
CallbackInterface_skel.class
5
CallbackInterface_stub.class
1. Client looks up the interface object in the RMIregistry on the server host.
2. The RMIRegistry returns a remote reference to the interface object.
3. Via the server stub, the client process invokes a remote method to register itself for callback,
passing a remote reference to itself to the server. The server saves the reference in its callback list.
4. Via the server stub, the client process interacts with the skeleton of the interface object
to access the methods in the interface object.
5. When the anticipated event takes place, the server makes a callback to each registered
client via the callback interface stub on the server side and the callback interface skeleton on the
client side.
6 Maart 2006
ISS 2006
55
Callback application files
Object client host
Object server host
object client directory
object server directory
Client.class
Server.class
ClientInterface.class
S erverInterface.class
S erverInterface.class
ClientInterface.class
ClientImpl.class
ServerImpl.class
S erverImpl_S tub.class
ClientImpl_S tub.class
ClientImpl_skel.class
S erverImpl_skel.class
6 Maart 2006
ISS 2006
56
RMI Callback file placements
Server host
Client host
client directory
server directory
SomeClient.class
SomeServer.class
CallbackInterface
_skel.class
SomeInterface
_stub.class
java.policy
SomeInterface.Skeleton.class
CallbackInterface
_stub.class
java.policy
HTTP Server
SomeInterface
_stub.class
6 Maart 2006
ISS 2006
57
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
58
Algorithm for building an RMI Callback Application
Server side:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Open a directory for all the files to be generated for this application.
Specify the remote-server interface, and compile it to generate the
interface class file.
Build the remote server class by implementing the interface, and compile it
using javac.
Use rmic to process the server class to generate a stub.class file and a
skeleton.class file: rmic SomeServer
If stub downloading is desired, copy the stub file to an appropriate
directory on the HTTP host.
Activate the RMIRegistry, if it has not already been activated.
Set up a java.policy file.
Activate the server, specifying (i) the codebase if stub downloading is
desired, (ii) the server host name, and (iii) the security policy file.
Obtain the CallbackInterface. Compile it with javac, then use rmic to
generate the stub file for the callback.
6 Maart 2006
ISS 2006
59
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
60
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
61
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
62
Summary-3

Client callback:

To provide client callback, the client-side software




The object server:



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.
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
63
Self study exercises

Chapter 7


Exercises 1,2,3 and 4
Chapter 8

Exercises 1 and 4
6 Maart 2006
ISS 2006
64