I have a java rmi server and an objective C client. I want to use RMI to HTTP tunneling in order to encapsulate the RMI calls into HTTP requests where an RMI servlet handler can forward the call into the corresponding rmi server.
However I'm facing an issue. Let's say for instance that I created the stub and bound the stub on the registry with a certain name (on the server side).
Now in objective C, how can I locate the registry and lookup the stub? because in normal cases where we have an rmi client, it can be done this way:
Registry registry = LocateRegistry.getRegistry(host);
Hello stub = (Hello) registry.lookup("HelloServer");
and these are not remote procedure calls that I can send in http requests for the server to handle them.
So how can I "locate" the server remote object in an objective C client?
Any help is appreciated and if you need more information please tell me.
You can't do this. RMI/JRMP requires a JVM. RMI/IIOP requires a JVM at the server and an ORB at the client (JVM contains an ORB for the server). IDL requires an ORB at the client as well, and you have to use the fully detailed CORBA API.
Related
I'm really new to Java RMI, and I don't quite understand what it actually does. When a remote method is called, is the method executed on the server, or the client? In other words does RMI utilize the servers resources or is it simply used for access to remote classes and methods which will run client side?
Java RMI (Remote Method Invocation) uses client side "stubs" to connect to server side implementation and the real work is done on the Server side.
This may seem like a simple question, but I can't find the definite answer:
Say I have three servers on a local un-firewalled network, one of which is the registry (R) and the other two are clients (A and B), and Client A and B both connect to the registry.
Client A obtains a reference to an exported object on B via the registry and invokes a method - does that method call go through the registry? i.e. if A passes a large byte array to B as a parameter to a method call, does that take 2 hops via R, or does the registry tell A that B can be communicated with directly?
No, calls from client to server to not pass through the RMI registry. The registry is only used to look up the reference to the server. Subsequent calls to the server go there directly.
The RMI registry is really nothing more than an RMI server itself, which accepts and stores remote stubs for servers which register with it. It provides a known point-of-entry for clients who don't know where to find the server. It hands the RMI stub back to the client, and the client then talks direct to the server via that stub.
What is RMI registry? What does it do?
Essentially the RMI registry is a place for the server to register services it offers and a place for clients to query for those services. See Introduction to Java RMI. Excerpt:
Figure 1 shows the connections made by the client when using RMI. Firstly, the client must contact an RMI registry, and request the name of the service. Developer B won't know the exact location of the RMI service, but he knows enough to contact Developer A's registry. This will point him in the direction of the service he wants to call..
RMI Registry acts a broker between RMI servers and the clients. The server "registers" its services in the registry - hence a RMI Registry can act as a "directory" for many servers/services. The client does not need to know the location of individual servers, and does a lookup on the RMI Registry for the service it needs. The registry, being a naming directory returns the appropriate handle to the client to invoke methods on.
Google around, there is plenty of info on RMI available.
Java's Remote Method Invocation (RMI) Registry is essentially a directory service.
A remote object registry is a bootstrap naming service that is used by RMI servers on the same host to bind remote objects to names. Clients on local and remote hosts can then look up remote objects and make remote method invocations.(Documentation)
You can use RMI or JNDI to bind and lookup your object remotely with rmi registry.
It's a well know use case of proxy design pattern. RMI servers register objects (essentially stubs) on RMI registry. Remote clients lookup these stubs and invoke methods on it. Behind the scene the method to be invoked, it's arguments are serialized and sent to the actual RMI server which has the implementation. RMI server (skeleton code) deserializes the request invokes actual method, collects results, deserializes it and send it back to the client (stub). Stub deserializes the results and returns it back to the code that invoked this method.
First the server associates a name with a remote object in the RMI registry. When a client wants access to a remote object it looks up the object, by its name, in the registry.
Then the client can invoke methods on the remote object at the server.
http://www8.cs.umu.se/education/examina/Rapporter/471App.pdf
I have a service object that can be connected to via RMI. Currently I'm doing this:
Server
Registry r = LocateRegistry.createRegistry(1234);
r.bind("server", UnicastRemoteObject.exportObject(remoteServer, 0));
Client
RemoteServer s = LocateRegistry.getRegistry("example.com", 1234).lookup("server");
The registry on the server has only one use, to link to the single server object. I figured I might just as well do this on the server:
UnicastRemoteObject.exportObject(remoteServer, 1234);
But then how would I connect to the server object from the client?
The RMI Registry exists to solve the RMI bootstrap problem, which is simply that you can only get a remote stub via a remote method call, and to perform a remote method call you need a remote stub. The Registry reference provided by LocateRegistry.getRegistry() solves this problem (and is used internally by Naming.lookup() if you are using that API). [Note that this stub isn't obtained via a remote method: it is synthethized locally using the host:port you provide. If they aren't correct you won't find out until you use the Registry stub.]
You have several choices to solve the RMI bootstrap problem:
Use the RMI Registry.
Use an LDAP server via JNDI with the LDAP provider.
Use UnicastRemoteObject, serialize the stub obtained when you export the object, and use a shared file, or a socket, or sneakernet, to make the stub available to clients.
Use RMI Activation; serialize the stub obtained when you registered the activatable, and distribute to all clients in a file, along with the client application. From the point of view of stub distribution this is a lot simpler than (3) because the stub remains constant for the life of the application, whereas in (3) you have to redestribute the stub on every export.
You can see that the Registry is certainly the simplest option. Note that you only have to use it to solve the bootstrap problem Once you have a stub, your own application remote methods can return further objects: you don't need more than one remote object in the Registry. You can consider that as a remote object factory.
Not impossible, but not terribly practical because the registry communicates the stub object of the exported object to the client (see http://www.developer.com/print.php/3455311). If you don't have another mechanism for that, you'll be stuck. Use of a registry in distributed systems has other benefits, so I'd actually recommend keeping it for other reasons (location transparency, etc).
Client uses an rmi URL like rmi://localhost:2020/server
see https://stackoverflow.com/a/61210297/503025
Trying to get an understanding on how the RMI is working (I have a simple application that uses RMI and seems to work just fine).
My question is : What happens when an rmi call is made? What happens on the way from an rmi client to an rmi server?
after the lookup described above, the objects used as parameters in a rmi call are serialized (Marshalling) that means a byte by byte representation of the objects non transient data will be send over the network connection. On server-side the serialized data will be unmarshalled and the objects will be instantiated. After that the server-side method is invoked, return values will be returned in a similar way as parameters have been previously send. It is similar to writing an object into a file.
http://java.sun.com/j2se/1.4.2/docs/guide/rmi/faq.html
RMI is the object oriented approach for RPC.
There is a Stub in client side and a Skeleton in server side. Client and Server does not directly communicate but they communicate over Stub and Skeleton which are generated automatically..
As you might guess there must be some objects both Server and Client have to use. These objects are defined in Server side and hold in RMI Registry. Both server and client can call RMI registry and it works as a memory somehow (It is not a Memory this is an example just to be clear). Server binds an object to registry and client invokes methods on it.