Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Jonathan Wolter
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex,

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

Paulo Crestani.
 
mohamed sulibi
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic