1. Java RMI, JAX-RPC and JWSDP
B. Ramamurthy

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

3. Implementation of RMI (5.2.5)

4. The role of proxy and skeleton in remote method invocation
server
client
remote
skeleton
object B
object A
proxy for B
Request
& dispatcher
for B’s class
Reply
servant
Communication
Communication
Remote reference
Remote
module
reference module
module
module
Object A invokes a remote object in Object B for which it holds a remote object
reference.
“System Model”

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

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

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

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

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

10. 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.
Reflection feature allowed for dynamic creation of skeleton and proxy in Java 2 version onwards.
Read more about reflection model of computing.

11. 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;
Object result = M.invoke(String, Args);

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

13. JAX-RPC
JAX-RPC (The Java API for XML-based RPC) is designed to provide a simple way for developers to create Web services server and Web services client.
Based on remote procedure calls; so the programming model is familiar to Java developers who have used RMI or CORBA.
Major difference between RMI and JAX-RPC is that messages exchanged are encoded in XML based protocol and can be carried over a variety of transport protocols such as HTTP, SMTP etc.
You can use JAX-RPC without having to be an expert in XML, SOAP, or HTTP.

14. The JAX-RPC Programming Model
Services, ports and bindings
JAX-RPC web service servers and clients
JAX-RPC service creation
JAX-RPC client and server programming environments
Stubs and ties
Client invocation modes
Static and dynamic stubs and invocation

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

16. Endpoint, Port and binding
Web service
endpoint
Port port port3
Web services Client
SOAP1.1
Over http
SOAP 1.1 over
https
Other. Ex:
ebXML over
SMTP
https 1.1 transport
soap1.1 messages

17. Web Service Clients and Servers
JAX-RPC maps a
web service operation to a java method call.
service endpoint to a Java Interface.
Thus one way to begin implementation of a web service in JAX-RPC is to define a Java interface with a method for each operation of the service along with a class that implements the interface. Of course, following the rules of remote invocation etc.
Now visualize client/server invocation in the same address space and lets compare it with remote invocation.

18. Local Date Service //server public class DataService {
public Data getDate() {
return new Date();}
//client
Public class Appln {
public static void main (..) {
DateService instance = new DateService();
Date date = instance.getDate();
System.out.println (“ The date is” + date); }
In the case of the remote call a layer of software is used to convey the method call from client to server. This layer of software is provided by JAX-RPC runtime.

19. JAX-RPC service creation
A service definition describes the operations that it provides and the data types that they require as argument and provide as return values.
This definition can be made available as a document written in WSDL.
From a WSDL document, JAX-RPC can generate the Java code required to connect a client to a server leaving one to write only the logic of the client application itself.
Since WSDL is language independent the server can be in .net, Jax-rpc or any other compatible platform.

20. JAX-RPC service creation (contd.)
Define the service a Java interface.
Generate WSDL using the tools provided with JAX-RPC package.
Advertise it in a registry for the client to lookup and import it.

21. Client and Server Programming Environment
JAX-RPC API is distributed over a set of packages:
javax.xml.rpc
javax.xml.rpc.encoding
javax.xml.rpc.handler
javax.xml.rpc.handler.soap
javax.xml.rpc.holders
javax.xml.rpc.server
javac.xml.rpc.soap

22. Stubs and Ties
Client Side: Stub object has the same methods as the service implementation class.
Client application is linked with the stub.
When it invokes a method stub delegates the call to the JAX-RPC runtime so that appropriate SOAP message can be sent to the server.
On completion the result return back in the reverse path as above.
Server side:
Message received must be converted into a method call on actual service implementation. This functionality is provided by another piece of glue called tie.
Tie extracts method name and parameter from SOAP message.
Tie also converts the result of the method call back into a response message to be returned to client JAX-RPC runtime.
JAX-RPC comes with tools to generate these.

23. Client Invocation Modes
Synchronous request-response mode (tightly coupled).
One-way RPC (loosely coupled): no value returned, no exception thrown, need to bypass stub layer, use Dynamic Invocation Interface (DII).

24. SEI Invocation Code Service End Point (SEI) invocation code:
Stub stub = (Stub)(new MyHelloService_Impl().getHelloIFPort());
stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
"
HelloIF hello = (HelloIF)stub;
resp = hello.sayHello(request.getParameter("username"));