Re: Java<->invoke RMI method by hand

On Mon, Mar 16, 2009 at 6:59 PM, Alex Co <[email protected]> wrote:

> 1. My objective: having a normal RMI server object running and connect it
> from other computer using a simple home made JVM without RMI not marshalling
> nor serializing capabilities. I think the serialization and marshalling can
> be implemented if needed. RMI is to heavy to be implemented on the home made
> JVM

From my PoV, RMI is something like 80% serialization and only 20%
network/transport/bootstrap/codebase handling.

> 2. It doenst matter if client side (homemade JVM application) will ve very
> bound to that specifica RMI server object. It doesnt matter for me. THe
> important things is: On server side must be a normal RMI Server object

Ok.

> 3. RMI deamon could be used on not.

Forget the rmid. Not important, and should probably not be used (at
least not initially).

> Questions:
> You said that on server side there is a ObjectId. This object ID lives on
> the rmi deamon right? What about if I connect directly to the server imple
> object without using the rmi deamon?

RMI works something like this (excluding the bootstrap);
1. The server creates the RemoteStub and puts inside it, among other
things (host, port...), the ObjectID (might be called something else
(it's years, almost decade, since Iooked at the details).

2. The RemoteStub is serialized to the client.

3. When the client calls a method in the RemoteStub, the ObjectID is
passed back to the server, so it can dispatch the call to the correct
exported object.


> Please could you clarify the importance of that ObjectID?

See above. RMI is a truly object oriented remoting solution, where you
can have 1000s of exported objects without severe resource
consumption.

> Whenyou say to get the Remote stub, serialize/deserialize it, marshall
> it/unmarshal it, execute it, I have to have a standard JAVA socket
> implementation and serialization and deserialization routines, right? I
> think that i can implement the serialization and marshalling routines but
> what about the stub object that was compilled using the sun JVM? It will
> have socket calls and things like that that will not have support on the
> home made JVM, right?

I am not able to understand your question.

Let's explain the bootstrap scenario;

The RMI Registry is a special Remote object due to, and only due to,
the fact that its ObjectID is well-known (i.e. 0). It is therefor
possible for the client to create a RemoteStub to the RMI Registry
without knowing anything previously. So, the
java.rmi.registry.Registry instance that is handed to you, is actually
a RemoteStub of the remote Registry. After that, when you do a
lookup(), it basically just take the RemoteStub of the looked up
server object and serializes it to the client.

Now, if you don't want to implement that, it is actually possible to
transfer the RemoteStub by any other means. I have previously managed
all kinds of funky transports, incl email, ftp, sockets and XMPP.

Coming back to you. It *may* be possible for you to dig up the
ObjectID of the remote object you want to connect to, and transfer
that number (it is not guaranteed to be the same any time you run)
over a socket and instantiate the RemoteStub manually on the client.
That is probably the "easy" part of your set up. To think that you can
execute any methods that takes arguments or return types, is a much
steeper exercise if I may guess. You will need to (at least partially)
to re-implement Object Serialization, and also implement the
MarshalledObject.

IF you can replace the RMI on the server with something similar, your
total effort is probably a lot less.


> Having a normal RMI server object running, can i use alternative
> serialization and RPC systems,
> such as Apache Thrift or Apache Etch (incubator) to connect to it?

No, not any one that I know of.
Again "normal RMI" is not very formative. If you have option to use
RMI-IIOP (PortableObject?), you may be able to dig up some IIOP
implementation that is light-weight enough for you. If you are stuck
with RMI-JRMP (UnicastRemoteObject), the download the spec (if you can
find it) and weep a silent tear. ;-)


If I were you; Assuming that the "server" is untouchable by all means.
I would place one other machine in between (much cheaper than all this
manual development) and have a bridging software in between, talking a
'simple' protocol to the weak devices and RMI to the server.

Cheers
Niclas
-- 
http://www.qi4j.org - New Energy for Java

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html