Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
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

The RMI Data Access Conundrum

 
Steve Hallinan
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have the B&S assignment and I'm at the design stage.
I have come across a problem that seems to be referenced to a good bit in the archives, but I have not been able to find a discussion that I could fully understand yet.

The Data Access class must implement an interface, DBAccess.
I would like to use RMI, so in addition to implementing this interface in my Remote class somehow, the interface should extend java.rmi.Remote, and the interface methods should throw RemoteException.

I would like to use a static factory method to get a local or remote Data Access instance, but what I am not clear about is whether or not it is permitted to make such a change to the specified interface in the instructions, ie extend Remote, and throw RemoteExceptions.

If it is not permitted, I cannot then implement the interface in both a local and remote class and from there use a DataAccess factory.

I would have to implement both a local and a remote interface, in which case to properly decouple the server from the GUI/model, I would have to use something like a Data Access strategy. This would involve duplication of logic and an extra dose of message passing, which is something that I am not happy about!

thanks in advance for any help/advice,
SteveO.
 
Seb Mathe
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personnaly I think it's better to let the interface provided by Sun unchanged.

Concerning RMI and the network/non network modes (I have the same problem than you), there's a pattern discussed here and elsewhere :



Where :

* Service interface defines business methods.
* ServiceImpl is the major implementation (deals with database)
* RemoteService extends Remote, redefine Service methods with throws RemoteException clauses
* RemoteServiceImpl is the object bounded in RMIRegistry, and delegates calls to a Service instance
* RemoteServiceWrapper delegates calls to a RemoteService instance.

Look at my post here.

Today I have always some doubts on those points : putting the business service server side or just the data access, how to track clients for locking...
I'm always finding new arguments for each solutions I've in mind...
 
Steve Hallinan
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks Seb!

I tried it out and it works.
It seems a fairly roundabout solution of what would otherwise be straightforward if you could modify the interface. But given you cannot do that, it is probably the best way. That also seemed to be the consensus of the threads you pointed me to.
Later,
steve.
 
Michael Valentino
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The interface wouldn't have to extend remote, but all the methods would have to conformto the remote method spec. In most cases, throwing RemoteException and making sure All returned objects are Interfaces should do the trick. However, I have the same B&S SCJD assignment and found myself thinking similar thoughts as you in regards to this. Just having my database interface methods throw RemoteException would allow the idea you mentioned above to work, but is this allowed? I'm currently checking with Sun on that one. If i don't hear back, I'm going to assume that it's NOT allowed.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic