Making Data "remotable"

[Marcos Motta]

Please comment this
The public methods of Data class can not be transformed in a remotable interface without modification. In order to be remotable, an impletentation of this interface must declare RemoteException on all methods. When implementing "DataInterface" the compiler will complain if I introduce a new checked exception (RemoteException) that existing clients might not be aware of.
My design was based on preserving compatibility with existing clients. Thus, I created RemoteDataInterface with all public methods of the original Data class, declaring RemoteException to each one. I also created RemoteConnection class, implementing RemoteDataInterface, wich is an adapter to the DataInterface. RemoteConnection keeps an instance of the Data class, delegating all method calls to it.
If I were not concerned with keeping compatibility with existing code I could make it simpler. Actually, I have not been told to act this way, but, I am assuming that I will be tested on making this kind of judgement, wich is "real life".
Is it Overdesign?
Do you think I should just create DataInterface with remotable methods and dont bother about this?
thanks

[Peter den Haan]

Originally posted by Marcos:
The public methods of Data class can not be transformed in a remotable interface without modification. In order to be remotable, an impletentation of this interface must declare RemoteException on all methods.

No. While the Remote interface must have a throws RemoteException in all its method signatures, there is no need for its implementations to do so.
By which I don't necessarily mean to say that it would be a good idea to turn Data into a Remote class. In fact, based on the information you give here your design is basically fine, but not for the reasons you're suggesting

[...] if I introduce a new checked exception (RemoteException) that existing clients might not be aware of.

What existing clients?

Is it Overdesign?
Do you think I should just create DataInterface with remotable methods and dont bother about this?

It's not overdesign, but I'm not sure what DataInterface buys you. At the very least, DataInterface should be a sub-interface of RemoteDataInterface (which should then really be renamed to RemotableDataInterface since implementations are not necessarily remote).
One way to approach this is to start with the most generic set-up and apply our trusty little razor to it.

/**
 * interface to a Data table which may be either local or remote
 */
interface DataInterface {
   void foobar() throws RemoteException;
}
/**
 * interface to a remote Data table
 */
interface RemoteDataInterface extends DataInterface, Remote {
}
/**
 * interface to a local Data table
 */
interface LocalDataInterface {
   void foobar();
}

Data would implement LocalDataInterface, RemoteConnection would implement RemoteDataInterface (note that its methods would generally not throw RemoteException).

/**
 * implementation of a remote Data table
 */
public class RemoteConnection extends UnicastRemoteObject implements RemoteDataInterface {
   ...
   public void foobar() {
      data.foobar();
   }
}
/**
 * implementation of a local Data table
 */
public class Data implements LocalDataInterface {
   public void foobar() {
      ...
   }
}

An application that needs local database support only would work with LocalDataInterface; an application which should work with either type of implementation (such as FBN) would use DataInterface.
Now it's time for the razor.
If you know that there will only ever be one local DataInterface implementation, you can dispense with LocalDataInterface. Data would implement DataInterface directly, and an application designed to work with local databases only would simply use Data.

/**
 * implementation of a local Data table
 */
public class Data implements DataInterface {
   public void foobar() {
      ...
   }
}

Also, if you're not particularly fussed that Data implements Remote, you can dispense with RemoteDataInterface and let DataInterface extend Remote.

/**
 * interface to a Data table which may be either local or remote
 */
interface DataInterface extends Remote {
   void foobar() throws RemoteException;
}
/**
 * implementation of a remote Data table
 */
public class RemoteConnection extends UnicastRemoteObject implements DataInterface {
   ...
   public void foobar() {
      data.foobar();
   }
}
/**
 * implementation of a local Data table
 */
public class Data implements DataInterface {
   public void foobar() {
      ...
   }
}

I'm personally not very fond of this last bit of razor action. Although I couldn't find a formal reason why Data cannot implement Remote, in my opinion an object which is not remoteable at all has no business being instanceof Remote. Others might disagree. In that case you can get things down to one single interface if you wish.
- Peter

[Mark Spritzler]

"Marcos"-
Welcome to the JavaRanch! Please adjust your displayed name to meet the
JavaRanch Naming Policy.
You can change it
here.
Thanks! and welcome to the JavaRanch!
Mark