aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S - Must RMI and Local DB interfaces need to be different? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S - Must RMI and Local DB interfaces need to be different?" Watch "B&S - Must RMI and Local DB interfaces need to be different?" New topic
Author

B&S - Must RMI and Local DB interfaces need to be different?

Jonathan Wolter
Greenhorn

Joined: Nov 26, 2007
Posts: 12
I have the Bodgitt and Scarper project, where there is a DB database interface.

I am using RMI, so I would like to have my RMI interface extend from the DB interface.

Problem:
I think RMI requires every method to throw RemoteException.

Yet, the DB interface given to me does not throw any RemoteExceptions (or any supertype such as IOException).


My Approach:
I duplicated the DB method signatures in another interface, DBRemote (except changing the throws to throw RemoteExceptions). This feels like a hack. Also, I now cannot interchange the remote or local implementation, since there is no polymorphism between the two. No common interface!

What can I do? Is this the best you can get when using RMI with an interface that does not throw RemoteExceptions initially?

To recap: I changed in DB.java (from Sun)


To this in DBRemote.java
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I have this requirement myself:


Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
public interface DBMain {}
...


Regards,
Alex
[ December 15, 2007: Message edited by: Alex Belisle Turcot ]
Jonathan Wolter
Greenhorn

Joined: Nov 26, 2007
Posts: 12
Alex,

I'm not sure to take your reply as a suggestion or a question. Thanks for posting, though. I have slightly different instructions.

Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

package suncertify.db;
public interface DB {...


This leaves me at the same spot I was before. Is there an approach when using RMI to reconcile two seemingly incompatible interfaces? One must throw RemoteException (right?), but the one given from Sun doesn't.

Jonathan
[ December 15, 2007: Message edited by: Jonathan Wolter ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I'm sorry, read your post too fast, I was just pointing out that your real Data Access Class should directly inherits the interface providing by SUN.

As for your real question

To me, yes, it's the best you can do. However, I personally don't use my data access class as the remote object.
You could create another object, using you data access. This other object being your business layer, could implement a well-designed interface for RMI...

Take a look at this amazing thread: Ken Krebs'

Regards,
Alex
[ December 15, 2007: Message edited by: Alex Belisle Turcot ]
Jonathan Wolter
Greenhorn

Joined: Nov 26, 2007
Posts: 12
Thanks for the post.

So if I were to add another object in for the business layer... whew, I'd then have 3 objects with almost the same responsibility: 1) DB.java (sun's interface), 2) this new business layer object, 3) The remote client that uses 2 and then 1.

Right now in my client code, I've abstracted out into 2 types of DB: local and remote. These are contained in a DBFacade object, which then transparently (to its clients) handles whichever Data access method is used.

This seems really ugly... can some of the duplication be cleaned up?

Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

for me, my "business" layer object does not have the same responsibility as the Data object.

Data is a DAO providing some higher abstraction of the different operations available on the database..

The business object contains the logic on how to use it and what is to be accessible (for instance, delete is not accessible). The methods are much more "business/client use cases" oriented: bookContractor, getContractors...

And the logic of lock/operation/unlock is performed there. The Data object is much more "stupid", does not have a clue what is going on..

That's, at least, my implementation, but that doesn't mean there aren't other ways..

As for the local and remote interface/implementation, with some clever inheritance, you can write all the business code only in the Local implementation.

Regards,
Alex
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

yes, the code is ugly

If both your local and remote object implement the same Interface, then you can use "Polymorphism" and handle both cases with a single variable.

Consider the following *pseudo*:


Regards,
Alex
Jonathan Wolter
Greenhorn

Joined: Nov 26, 2007
Posts: 12
Thanks for your post.

For me Data.java must implement the sun provide DB.java interface. I wanted to use polymorphism for my Local and Remote objects (both would implement DB). But because Data.java threw method signatures that were incompatible with the requirements for RMI, I couldn't.

Fast forward to your suggestion: Add a business layer in to separate my application from the DAO*. Then, look at polymorphism in that business layer so that my remote and local objects can implement the same interface. That's my next step.

Thanks,

Jonathan
* http://en.wikipedia.org/wiki/Data_Access_Object
** http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Harjit Singh
Ranch Hand

Joined: Feb 01, 2007
Posts: 77
I was able to figure this out. Let me know if you need help....

Thanks

- Harjit


Originally posted by Jonathan Wolter:
Thanks for your post.

For me Data.java must implement the sun provide DB.java interface. I wanted to use polymorphism for my Local and Remote objects (both would implement DB). But because Data.java threw method signatures that were incompatible with the requirements for RMI, I couldn't.

Fast forward to your suggestion: Add a business layer in to separate my application from the DAO*. Then, look at polymorphism in that business layer so that my remote and local objects can implement the same interface. That's my next step.

Thanks,

Jonathan
* http://en.wikipedia.org/wiki/Data_Access_Object
** http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
wumi adisa
Greenhorn

Joined: Jan 02, 2008
Posts: 1
I create an adapter class to solve the problem . Check out this site to read on adapter design pattern : http://www.javaworld.com/javaworld/jw-05-1999/jw-05-networked.html?page=2 . I hope it helps .
Paulo Crestani
Greenhorn

Joined: Nov 06, 2007
Posts: 19
Jonathan,

I have just had the exact same problem you described and I decided to write to the ranch when I realized the best solution I could find for that would be the same non-polymorphic implementation you also found ugly. I almost gave up RMI and tried a sockets solution.

Well, at least it seems there is not a better solution. Even the adapter solution seems to be just that of having two different interfaces, one for the remote case and the other for the local case and on the client side someone still has to mediate which one to use in each case.

I will keep an eye on this conversation in case a better approach is described. Thank you.

Paulo Crestani.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I was pretty sure my suggestion (earlier in this post) put an end to the ugly solution..

You use the same object either to create/use the local or remote implementation.



For me, this is a beautiful solution

Regards,
Alex
Paulo Crestani
Greenhorn

Joined: Nov 06, 2007
Posts: 19
Alex,

Now I can see your solution. Indeed it is a very nice approach.

Paulo Crestani.
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
hi all;

i think from a Design pattern view this is called factory pattern or factory method pattern or abstract factory pattern, any way , what you think about this instead :



i think it is not agood idea to pass a boolean value to constructor to
build its data , what other think .

m_darim
SCJP, SCJD in progress ...
Paulo Crestani
Greenhorn

Joined: Nov 06, 2007
Posts: 19
mohamed,

You are right. In coded my solution just this way you said, based on Alex�s approach. I made my business class a factory and two overloaded getInstance() methods, on for the local connection and the other for the remote connection. That is ok.

Paulo C.
Morten Franorge
Ranch Hand

Joined: Jul 29, 2005
Posts: 137
Originally posted by Alex Belisle Turcot:
Hi,

I was pretty sure my suggestion (earlier in this post) put an end to the ugly solution..

You use the same object either to create/use the local or remote implementation.



For me, this is a beautiful solution

Regards,
Alex


So the MyBusinessInterface throws remoteexception? And the client code have to handle remote exception, even when the actual implementation (the local) will never throw a remote excepion. Just for the benefit of having a unified interface?


SCJP 1.4, SCBCD 1.3, SCBCD 5.0, SCEA J2EE, SCEA 5.0
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S - Must RMI and Local DB interfaces need to be different?