Java RMI and WS
B. Ramamurthy
Page 1
Inside RMI
• http://java.sun.com/j2se/1.5.0/docs/index.html
• Basic RMI classes: /usr/java1.1/src/java/rmi
–
–
–
–
–
java.rmi.registry.*
java.rmi.Naming class (static/class methods)
java.rmi.Remote interface (marker interface)
java.rmi.server.*
Default RMI port 1099
– Both lookup from local and remote are
acceptable.
Page 2
Implementation of RMI (5.2.5)
Page 3
The role of proxy and skeleton
in remote method invocation
server
client
object A proxy for B
Request
skeleton
& dispatcher
for B’s class
remote
object B
Reply
Remote Communication
reference module module
servant
CommunicationRemote reference
module
module
Object A invokes a remote object in Object B for which it holds a remote object
reference.
“System Model”
Page 4
RMI Internals: Communication
Module
• Carries out request-reply protocol;
• On the client side {message type, message
id, remote reference to object} are gathered
and sent out. At most once invocation
semantics;
• On the server side, it gets local reference for
remote reference from remote reference
module, invokes a dispatcher with this
reference.
• See UnicastRemote (implements
UnicastRemote)
Page 5
RMI Internals: Remote
Reference module
• Responsible for translating between
local and remote object references and
for creating remote object references.
• A remote object table has a mapping
between local and remote references. A
table at server (entry for object ref for
B) and a table at client (entry for object
ref for proxy B).
Page 6
RMI Internals: Remote
References
• Action of remote reference module: See
RemoteRef.java interface
– When a remote object is to be passed as
argument or result for the first time, the remote
ref is asked to create a remote ref object which is
added to the table.
– When a remote object reference arrives in a
request or reply, the remote ref module is asked
for corresponding local object ref, which may
either a proxy or remote object. If it is not in the
table RMI runtime creates it and asks remote ref
module to add it to the table.
Page 7
RMI Internals: RMI software
•
•
•
•
•
•
•
•
Layer of software between application level objects and communication
and remote reference modules: “Middleware”
Proxy: provides remote access transparency. One proxy for every remote
object in the client.
Dispatcher: A server has one dispatcher and skeleton for each class
representing a remote object.
– It receives request message from comm. Module
– It used MessageId to select appropriate method in skeleton.
– Proxy and dispatcher use same MessageId.
Skeleton: A class of remote object has a skeleton that implements of the
remote interface. All the access dependencies are hidden in this class. A
remote object has a servant that directly implements the methods. Java 5
creates this dynamically.
Proxies, dispatcher and skeleton are automatically generated by interface
compiler.
Binder: binds textual names to remote object references. RMiRegistry is a
binder; Naming class; see fig.5.13
Server Threads: one thread per invocation
Distributed garbage collection: See Andrew Birell’s paper [1995].
Page 8
RMI Internals: Distributed
Garbage Collection
•
•
•
•
•
•
•
•
•
Based on reference counts.
Local garbage collectors and a distributed support.
Each server holds the list of processes that hold remote object references: for
example, B.Holders
When a client C first receives a remote reference to a particular remote object,
say B, it makes a addRef(B) invocation to server of that remote object and then
creates proxy; server adds C to B.Holders.
When client C’s garbage collector finds that proxy is no longer reachable (ref
count), it makes a removeRef(B) invocation to server and then deletes proxy;
the server removes C from B.Holders.
When B.Holders is empty, server’s local garbage collector will reclaim the space
occupied B unless there are any local holders.
These extra calls for updates occur during proxy creation and deletion and do
not affect normal opertion.
Tolerates communication failures: addRef() and removeRef() are idempotent:
effects of N > 0 identical requests is the same as for a single request.
If addRef() fails with an exception, proxy is not created, removeRef() is
transmitted; removeRef() failures are dealt with by “leases” (Jini kind).
Page 9
RMI Internals: Use of
Reflection
• What is reflection? (See Reflection package)
• Reflection enables Java code to discover
information about the fields, methods and
constructors of loaded classes, and
• To use reflected fields, methods, and
constructors to operate on their underlying
counterparts on objects, within security
restrictions.
http://java.sun.com/docs/books/tutorial/reflect/class/index.html
• Reflection feature allowed for dynamic creation of skeleton and
proxy in Java 2 version onwards.
• Skeleton has been deprecated since JDk1.4.x
• Read more about reflection model of computing.
Page 10
A Little bit of Reflection
• Method class, invoke method
• Invoke method requires two
parameters: first the object to receive
invocation, second an array of Object
parameters.
• Invoke executes the method on the
object and returns result as Object.
• Method m;
11
• Page
Object
result = m.invoke(String, Args);
Using Reflection in RMI
• Proxy has to marshal info. about a method and its
•
•
•
•
•
arguments into a request message.
For a method it marshals an object of class Method
into the request. It then adds an array of objects for
the method’s arguments.
The dispatcher unmarshals the Method object and its
arguments from request message.
The remote object reference is obtained from remote
ref. table.
The dispatcher then calls the “invoke” method on the
object reference and array of arguments values.
After the method execution the dispatcher marshals
the result or any exceptions into the reply message.
Page 12
Putting it all together
Server side:
 Write a an interface and implement it.
Implements Remote,
 Inside code publishes the object by
(exporting to runtime) and by registering it.
Client Side:
 Code: look up server object name from the
registry {host, port};
 Invoke operations.
Page 13
Lifecycle of a remote call
1. First time, an operation is invoked, remote
object reference is obtained from remote
registry, addRef() is sent to remote server,
an entry made in the local ref table and
proxy is created.
2. Proxy has message ids while the client’s ref
table has remote object reference.
3. Remote ref, method id and arguments are
marshaled into a message and sent across
via the communication module.
Page 14
Lifecycle of a remote call (contd.)
• On the server side RMI runtime maps the
remote reference to a local object.
• Unmarshalls the operation and parameters
and uses reflection to “invoke” the method on
the object reference.
• The result is marshaled back into the
response and sent back to the caller.
• “Skeleton” that includes the “dispatch” is
subsumed into the RMI runtime in the latest
versions of Java.
Page 15
Critique of RMI (Sun Java’s) /RPC
(Microsoft’s)
• Performs very well for single-platform limited
•
•
•
•
•
•
•
distributed system.
Platform dependent
Tightly coupled
Inherently synchronous (No chance for eventing or
notification)
Object-oriented: Objects not deployable units
Non-standard
Not scalable, location dependent, no global
registry/discovery
Object reference passed as parameter and/or
returned as result.
Page 16
Interface Semantics
Process1
Process2
getCustomer()
retrieveCustomerData()
returnResult()
Semantics of the activity is explicitly stated in the message/method call
Page 17
Payload Semantics
Envelop
With
message
Process 1
Process 2
Requested transaction/activity is embedded in the message
Details of the activity not explicit; the semantics are embedded in the message
Page 18
Payload Semantics
Client
Queue
Server
createMes s age()
s endMes s age()
onMessage()
receiveMes s age()
receiveMes s age()
Page 19
Payload semantics is generic
String transferMoney (amt: decimal,
accTo: String)
{ …}
String executeService (message: String)
{ …}
Page 20
XML
• XML is a markup language, developed by
W3C (World Wide Web Consortium), mainly
to overcome the limitations of HTML.
• But it took a life of its own and has become a
very popular part of distributed systems.
• We will examine its definition, associated
specifications (DTD, XSLT etc.), Java APIs
available to process XML, protocols and
services based on XML, and the role XML
plays in a distributed computing environment.
Page 21
Memo.html vs memo.xml
<!DOCTYPE html PUBLIC "-//W3C//DTD
HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<title>memo.html</title>
</head>
<body>
<h3>Hello World</h3>
Bina<br>
CSE4/586 Students <br>
Good Morning everyone<br>
BR<br>
<br>
</body>
</html>
Page 22
<?xml version="1.0" ?>
<!DOCTYPE memo (View Source for full
doctype...)>
- <memo>
<header>Hello World</header>
<from>bina</from>
<to>CSE4/586 Students</to>
<body> Good Morning
everyone</body>
<sign>br</sign>
</memo>
XML to SOAP
• Simple xml can facilitate sending
message to receive information.
• The message could be operations to be
performed on objects.
• Simple Object Access Protocol (SOAP)
Page 23
Web Services
•
•
•
•
•
•
•
Web Services is a technology that allows for applications to
communicate with each other in a standard format.
A Web Service exposes an interface that can be accessed
through messaging.
Deployable unit.
A Web service uses protocol to describe an operation and the
data exchange with another web service. Ex: SOAP
Platform independent, say, through WSDL.
Publishable, discoverable, searchable, queryable
Scalability issues: A group of web services collaborating
accomplish the tasks of a large-scale application. The
architecture of such an application is called Service-Oriented
Architecture (SOA).
Page 24
Web Services and SOA
• Web Services is a technology that allows for
applications to communicate with each other in a
standard format.
• A Web Service exposes an interface that can be
accessed through XML messaging.
• A Web service uses XML based protocol to describe
an operation or the data exchange with another web
service. Ex: SOAP
• A group of web services collaborating accomplish the
tasks of an application. The architecture of such an
application is called Service-Oriented Architecture
(SOA).
Page 25
A Little bit of History: XML to
SOAP
• Simple xml can facilitate sending
message to receive information.
• The message could be operations to be
performed on objects.
• Standardize the tags for object access.
• Simple Object Access Protocol (SOAP).
Page 26
SOAP Request (Not WS request)
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productId>827635</productId>
</getProductDetails>
</soap:Body>
</soap:Envelope>
Page 27
SOAP Reply
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse
xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName>
<productId>827635</productId>
<description>3-Piece luggage set. Black
Polyester.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
Page 28
SOAPWeb Services (WS)
Take a look at
1. http://www.w3.org/DesignIssues/WebServices.html
2. O’Reilly book on Web Services: Kim Topley’s Webservices
in a Nutshell:
http://www.oreilly.com/catalog/javawsian/index.html
This link has a sample chapter (SAAJ) and zip of all
examples in the book.
Page 29
Web Services (Colouris)
• A web service provides a service interface
enabling clients to interact with servers in
a more general way than web browsers
do.
• Clients access operations in the interface
usually by XML messages over http.
• However other architectural models such
as REST and CORBA could access WS.
• WSDL provides additional details than for
standard operation: for encoding, security,
communication
and location.
Page 30
Web services infrastructure and
components
Applications
Directory
service
Web Services
Security
Choreography
Service descriptions (in WSDL)
SOAP
URIs (URLs or URNs)
Page 31
XML
HTTP, SMTP or other transport
SOAP message in an envelope
envelope
header
header element
header element
body element
body element
body
Page 32
Example of a simple request without
headers
env:envelope
xmlns:env =namespace URI for SOAP envelopes
env:body
m:exchange
xmlns:m = namespace URI of the service description
m:arg1
Hello
m:arg2
World
In this figure and the next, each XML element is represented by a
shaded box with its name in italic followed by any attributes and its
content
Page 33
Example of a reply corresponding to the
request in
env:envelope
xmlns:env = namespace URI for SOAP envelope
env:body
m:exchangeResponse
xmlns:m = namespace URI for the service description
m:res1
World
Page 34
m:res2
Hello
POST /examples/stringer
endpoint address
Host: www.cdk4.net
Content-Type: application/soap+xml
Action: http://www.cdk4.net/examples/stringer#exchange
<env:envelope xmlns:env=namespace URI for SOAP
> envelope
<env:header> </env:header>
<env:body> </env:body>
</env:Envelope>
Page 35
action
HTTP
header
SOAP client-server
communication
Services, ports and bindings
• Service endpoint interface (SEI) or service
endpoint that defines one or more operations
that the web service offers.
• Access to an endpoint is provided by binding
it to a protocol stack through a port.
– A port has an address that the client can use to
communicate with the service and invoke its
operations.
• An endpoint can be bound to different ports
each offering a different suite of protocols for
interaction.
Page 36
Endpoint, Port and binding
Web service
endpoint
Port1
SOAP1.1
Over http
port2
SOAP 1.1 over
https
port3
Other. Ex:
ebXML over
SMTP
https 1.1 transport
soap1.1 messages
Page 37
Web services Client
WS Interoperability Infrastructure
WSDL
Service Description
SOAP
XML Messaging
HTTP
Network
Page 38