wood burning stoves*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: DB interface v.s. RemoteException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: DB interface v.s. RemoteException" Watch "B&S: DB interface v.s. RemoteException" New topic
Author

B&S: DB interface v.s. RemoteException

Michael Vargenstien
Ranch Hand

Joined: Jan 27, 2007
Posts: 61
Hello Everybody,

I've come across something I'm not quite sure how to solve. I had chosen RMI to be my client to server solution but I'm kinda confused now. According to some research I've done, all public methods must throw a RemoteException. The problem is my DBImpl class which implements the DBAccess and Remote classes has custom exceptions like RecordNotFoundException, etc. Because of this, I can not throw a RemoteException becase that will NOT implement the DBAccess interface, i.e. the Data class. How should I approach this?

Thanks!!
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3285
    
    7
It seems you are trying to make DBImpl a remote class. Instead of that you can create a business interface with appropriate high level methods such as search and book, and implement that interface through a remote class (and a non-remote class for non-networked version). The implementation classes will use the DBImpl internally. The methods of DBImpl will declare RemoteException.


Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Michael Vargenstien
Ranch Hand

Joined: Jan 27, 2007
Posts: 61
Exactly!!! I was thinking about that last night. If a remote db interface is exactly the same with the exception that all the appropriate methods throw RemoteException, then it will not "break" the interface and it will still can use the orignal (sun) db interface instead. Apply an adapter type pattern. This will give the best of both worlds. So in essence, it will be a wrapper to another wrapper.
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3285
    
    7
Originally posted by Michael Vargenstien:
Exactly!!! I was thinking about that last night. If a remote db interface is exactly the same with the exception that all the appropriate methods throw RemoteException, then it will not "break" the interface and it will still can use the orignal (sun) db interface instead. Apply an adapter type pattern. This will give the best of both worlds. So in essence, it will be a wrapper to another wrapper.



I think I need to clarify further. Instead of creating a remote DB interface, think about a remote server interface. Which means, you should expose business methods (and not low level DB methods) remotely. So, you client application will call high level business methods such as book() on your server, instead of low level methods provided by DBImpl.
Marco Santinon
Greenhorn

Joined: Jan 03, 2007
Posts: 17
I introduce myself in this topic to clear what I have in mind...

I have RMI class that implements RMIInterface with methods that throw RemoteException

I have olso a server class that implement a CustomInterface with methods that throw CustomException

the server class uses my data.class, given with the assignment.

And my RMI class uses the server class.

The idea is to have only one interface that will be implemented by the RMI class and by the server class, so that the client will notice no difference in network and no-network mode.

So this ServerInterface has methods that throw both, RemoteException and CustomException

Am I right?

Thaks

Marco
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S: DB interface v.s. RemoteException