FBN: RMI Server Design

[James Clinton]

Hi Ranchers,
I am puzzled on how to design the server after reading the following post, which states that data.class shouldnt be a remoteable object.

Create a separate server class extending UnicastRemoteObject (which implements Remote). This is the remote server that clients somehow attach to. This class can then access Data on behalf of the client. You probably don't want to make Data (or a subclass of it) remoteable. After all, Data will have to be used locally at the client as well, to meet the local-mode requirement.


My current data.class is as follows:

public class Data extends UnicastRemoteObject implements DataIF

Am I on the right track here or will I hit local/remote problems.
Or should I implement another layer as suggested, which simply invokes methods on the data.class as follows:

public synchronized String getMsg()
{
   Data d = new Data();
   return d.getMsg();
}

To summarise my gunff.
Should I make data.class a remote object or not, and if it is a remote object, am I going to hit problems when attemping to make local method calls.
Hopefully I am making sense here.
Please advise me on the right path to take..
Thanks.
/ James

[Christian Garcia]

James,
My advice is to separate the implementation of the Data class into Local and Remote versions. If you modify the Data class to implement the Remote Interface and extend UnicastRemoteObject, that will cause definite issues for you. One major pain will be how you handle exceptions.
A 'remote' object must throw RemoteException from all of its' methods. Having a 'local' version of Data throwing that type of exception doesn't really make sense.
You already have the 'local' implementation of the Data class. I create an instance of it directly on the local machine for my project typed as LocalDataInterface. On the RMI side I have a RemoteData class that performs the same actions as the Data class, but from a Remote context (i.e. through the RMI registry). I return instances of it as RemoteDataInterface.
HTH

[James Clinton]

Thanks for the reply Christian,
Just so I understand what you are suggesting, I'd like to clarify.
I need to implement two Data classes.
1. LocalData.class (implements LocalDataIF) Doesn't throw RemoteExceptions.
2. RemoteData.class (extends UnicastRemoteObject implements RemoteDataIF) does throw RemoteExceptions.
Each with there own interface, because ofcourse as you say, only remote objects throw RemoteExceptions.
Could this solution compromise the thread safetly issues on the server-side. If a local and remote call was made at the same time (because in theory they are accessing the same file via different objects.) ?
Plus this implementation means that I have 2 interfaces which are identical apart from the exceptions throw (same for Data.class).
Is that right, or am I not understanding what you are suggesting?
Thanks, much appreicated..

[James Clinton]

Also ranchers.
Please see this comment from google groups on the subject too.
-Recognizes RMI that this is a local call?

-- Don't think that was implemented as of 1.3, not sure about 1.4 (although I doubt it really). There was a Very Good Reason why this doesn't happen, which I can't remember now...
--- It will never be implemented. RMI calls are defined as having argument-copy semantics, which would be violated if an RMI was executed
as a local call."
/ James (still confused)

[Andrew Monkhouse]

Hi James,

I need to implement two Data classes.
1. LocalData.class (implements LocalDataIF) Doesn't throw RemoteExceptions.
2. RemoteData.class (extends UnicastRemoteObject implements RemoteDataIF) does throw RemoteExceptions.
Each with there own interface, because ofcourse as you say, only remote objects throw RemoteExceptions.

I would advise against this: it is not very object orientated - you will end up with almost identical code in both your classes.
My recomendation would be to develop a more modular solution. In this case, you will develop a Data class, that only implements LocalDataIF. Do not worry about how this connects to the outside world for the moment - all you are developing is a Data class that provides access to the Data.
Once you have your Data class built and working, you can then start to think about how you connect to it. You can then build another class to provide remote access to the Data class. From what you have been describing, you are planning on using RMI. So this new class would provide your RMI access. You can also create a class to provide local access to the Data class if necessary.
Since this approach is modular, you could have other classes as well, all providing different forms of access. This makes it nice and extensible for the future. Say for instance that a later requirement was for MQ connectivity. Since this is modular, you can just add another class which does the MQ work.
This approach also means that you do not have one class trying to do too much work. In trying to do too much work, your class will become bloated, hard to understand, and hard to add functionality. A general rule of thumb is: whenever you describe a class, you should try and avoid AND or OR statements in your description. The way you were trying to describe your Data class would have been something like "Accesses the data, AND provides either RMI OR local access to the data".
Regards, Andrew

[James Clinton]

Ahh I see.
So then my RMI class would then implement some remote interface making whatever services available to remote clients.
Essentially this rmi class acts as another layer.
If I have NOT understood that incorrectly pls comments, otherwise many thanks, I can now picture how its going to function.
/ James

[Christian Garcia]

I failed to properly describe my Remote implementation. I didn't recreate the code of the Data class into a 'RemoteData' version. My implementation uses the Adapter pattern on the server-side.
I do use two interfaces: LocalData and RemoteData. RemoteData implements Remote to mark the object as a "remote" object. RemoteData implements LocalData and throws RemoteException for all of the methods. This relationship between LocalData and RemoteData is possible because IOException thrown in LocalData is the superclass of RemoteException thrown in RemoteData.
I apologize for omitting this information.
[ July 01, 2003: Message edited by: Christian Garcia ]

[James Clinton]

No problem Christian, thanks for posting...
/ James