aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Remoting layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Remoting layer" Watch "Remoting layer" New topic
Author

Remoting layer

Kannan Ekanath
Greenhorn

Joined: Nov 26, 2008
Posts: 18
Ok, I have already seen the related threads
here and here

I was given a DB interface
interface DB {
public long lock(int recNo) throws RecordNotFoundException;
}

For Remoting I wrote a
interface RemoteDB extends DB, Remote{
}

And the RemoteDBImpl class looks like
class RemoteDBIMpl extends UnicastRemoteObject implements RemoteDB{
public long lock(int recNo) throws RecordNotFoundException {
//delegate to the actual object
}
}

There is a problem in exporting the RemoteDBImpl since the exportObject method complains that the signature is illegal. Here is the problem
1) If I say the lock method to throw RemoteException as well, then it gives compilation errors since the extended interfaces cannot throw new exceptions
2) If I make RemoteDB interface to not extend DB and just copy over the interface methods, then my Controller which presently works with DB interface (irrespective of whether it is a local or remote connection) cannot work.

Can someone tell me what solution they devised for these problems?
[ December 06, 2008: Message edited by: Kannan Ekanath ]
Kannan Ekanath
Greenhorn

Joined: Nov 26, 2008
Posts: 18

[ December 06, 2008: Message edited by: Kannan Ekanath ]
Attila J�borszki
Greenhorn

Joined: Oct 11, 2008
Posts: 13
I ran into a similar problem also.

You should remove the "extends DB" from RemoteDB declaration.
This is needed if you do not want to change the DB interface. I guess, Sun does not allow to change its interface.

The problem is that the methods of the class, you want to send through RMI, have to be declared throwing RemoteException. If you leave "extends DB" in the declaration of RemoteDB, you should change methods of DB to throwing RemoteException.

You should imagine RemoteDB as a wrapper class for DB. Methods of RemoteDB should throw RemoteException. The client will see the remote database through RemoteDB.

And I think, you should use a 3rd interface for Controller on the client side to hide the difference between RemoteDB and DB.


I guess, you also used the Monkhouse book ... It is a trick in this book that Monkhouse defined his DBClient methods throwing IOException. In this way, the DBClient methods can throw RemoteException also because RemoteException is an IOException. So, he could insert "extends DBClient" into the declaration of DvdDatabaseRemote. But this solution works only if the methods in Sun provided interface (DBMain, I guess) throw RemoteException or IOException.

Regards,
Attila
[ December 07, 2008: Message edited by: Attila J�borszki ]
Kannan Ekanath
Greenhorn

Joined: Nov 26, 2008
Posts: 18
Spot on Attila. That was the exact solution I came up with.

DB is the standard interface (which unfortunately doesnt throw IOException or RemoteException)

If DBRemote extends DB then that is when problem arises in that any implementation of DBRemote cant be exported.

Solution:
DBRemote - does not extend DB but copy over all methods in DB and alter the signature to throw RemoteException
DBRemoteImpl extends UnicastRemoteObject implements DBRemote - and show can be exported (It has a DB object of instance DBImpl to which it delegates to)
DBAdapter implements DB - And is constructed with a DBRemote object. So it calls the corresponding methods on DBRemote and catches RemoteExcpetion only to rethrow it back

Round about, but probably the only elegant way of doing it
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Remoting layer