question on server binding

[kevin ou]

hi all
I have been reading the forum about the connection object, people are letting the server binding a connection Object. My question is that can I let the server to bind remoteData Object instead. Also, I want to know what is the benefit for creating the connection Object. I appreciate!
kevin

[Andrew Monkhouse]

Hi Kevin,
Welcome to JavaRanch.
An explanation on why some (not all) people were binding a connection object rather than binding a remote data object.
People working on the old assignment had a design issue where the instructions told them that their network interface had to provide the method void lock(int record) (and others), and another requirement was that a client could only unlock records that it had locked.
Some of the new assignments seem to have a different signature: cookie lock(int record) .... if you have cookies it is easy - the client must provide the returned cookie in all other methods in order to work with the record.
If you use sockets it is easy - you know which client is connected on a particular socket, so you can know whether they have locked the record or not.
But with RMI you have a problem - each invocation of a remote method may be on a different socket. In practice, I think that if two invocations are within about 20 seconds of each other they will be on the same socket, otherwise they get different sockets.
Because of this, there is a problem - there is nothing on the server side to identify which client is trying to modify or unlock a given record.
One solution to this is binding a connection object. That way, the client will always have the same connection object to work with, therefore you have something you can use to identify the client and make sure they dont unlock (or modify) anything they didnt lock.
There are other solutions though, so not everyone has gone down this path.
And if you are lucky enough to have the new exam which explicitly requires cookies, then it is a non issue for you.
So, yes, you can bind your remote data object, as long as you feel you can meet your requirements.
Regards, Andrew

[kevin ou]

hi Andrew
Thank you for your reply.
I think I will go down that road and I appreciate for your suggestion! And I want to know that if I bind the connection object, do I need to make that remoteData Object to extend the UnicastRemoteObject too?
kevin

[Andrew Monkhouse]

Hi Kevin,
Sorry for the delay replying ... got tied up in other things.
Re reading my post, I saw I wrote: But with RMI you have a problem - each invocation of a remote method may be on a different socket. In practice, I think that if two invocations are within about 20 seconds of each other they will be on the same socket, otherwise they get different sockets.
I should have said that each invocation of a remote method may have a different thread (client socket may also change between invocations but that is a seperate issue).
Anyway, to your question: And I want to know that if I bind the connection object, do I need to make that remoteData Object to extend the UnicastRemoteObject too?
Yes, the remoteData object will also need to extend the UnicastRemoteObject. And I think that is what most people are doing (but comments later might show another thing you can do).
So you have something like:

Server extends UnicastRemoteObject provides getClassA() which creates a new ClassA and returns the reference to it to the calling class.

Class A extends UnicastRemoteObject, provides access to the Data methods.

It would get used something like:

  Object remote = Naming.lookup("Server");
  Data myData = (ClassA) ((Server)remote).getClassA();
  myData.lock(1);

Note that you only need to bind the server classes functions to the rmiregistry. You do not need (or want) to bind the ClassA functions to the registry.
Not sure if the code I have written there is 100% accurate - just wrote it off the top of my head.

Make sure you are happy with that before headin g on to the next part of my post (note: the next part is not necessary, but it has been included for completeness and because it may be interesting).

Moving away from the minimum required, you can also have multiple levels of indirection:

Server extends UnicastRemoteObject provides getClassA()

Class A implements serializable, internally gets an instance of class B. Wraps the methods returned by class B.

Class B extends UnicastRemoteObject, provides access to the Data methods.

This would get used the same way:

  Object remote = Naming.lookup("Server");
  Data myData = (ClassA) ((Server)remote).getClassA;
  myData.lock(1);

Totally confused yet?
Here is the interesting bit: Because ClassA is serializable, it actually got downloaded to the client! So when the user attempts to call the unlock() method, you can verify on the client side whether they have locked the record or not. If they have not locked it, you can give back an immediate response ... no network traffic required !!!
And the client is unaware of it! They think they just called the unlock() method on the server.
Is it worth the extra coding ... I decided against it. Mainly because I want to track locks server side in order to handle unlocking if the client dies, and I didnt want locking in multiple places, and limiting network traffic is not a requirement.
But I thought I'd mention it because it is so cool :-D
Regards, Andrew

[kevin ou]

hi Andrew
Thank you for your help. I will take your suggestion.
kevin