• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Implementaion of the interface provided by Sun to handle local and remote connections

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My server implementation is as below.

Sun has provided the DB interface. My Data.java provides the implementation for this.
I use Data directly to make the application work in local mode.

But for Remote mode I have an issue. I have to throw the RemoteExceptions to heed to the RMI conventions. So I wrote a new interface RemoteDB having the same methods as DB. The only difference being they all throw RemoteExceptions as well.

The RemoteDbImpl extends UnicastRemoteObject and implements RemoteDB. For implementing the methods in RemoteDBImpl, I use the methods implemenation is Data class.
e.g. in RemoteDBImpl , the read method is something like

public String[] read(int recNo) throws RecordNotFoundException, RemoteException {
return db.read(recNo);
}

where db is an instance of Data class.

In the Client side I have a DBAdapter class that implements DB. This helps me to produce a DB type object independent of the mode(local or remote).
So In DBAdapter my code is something like

public String[] read(int recNo) throws RecordNotFoundException {
String[] result = null;
try{
result = remotedb.read(recNo);
} catch(RemoteException Rex) {

}
return result;
}

Please let me know if you see any flaws here or can think of a better approach. Any help is highly appreciated!
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Priya

This is what I did.

I implemented the DBAccess interface in a class I call DBAccessImpl. Then, I created a Remote interface, which I call Server, and I have a ServerImpl, as well, which is actually a wrapper class over the DBAccessImpl.

This ServerImpl will be the remote object I am going to export. Nevertherless I did not extend UnicastRemoteObject (URO), because UROs automatically register themselves in the registry.

Therefore I register my remote objects manually, only when the application has to work on server mode. When it is working on standalone mode, I just obtain a reference of the object and use it locally.

I hope this helps!
[ August 04, 2006: Message edited by: Edwin Dalorzo ]
 
Priya Patra
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Edwin for the quick reply. Your server implementation looks almost the same to me. Did you find any difference there?

Also, I am a novice to RMI and one thing is not clear to me. What do you mean when you say "Nevertherless I did not extend UnicastRemoteObject (URO), because UROs automatically register themselves in the registry."
I am registering it programmatically using the CreateRegistry and Naming.rebind.

Am I missing something here?
 
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

... UROs automatically register themselves in the registry.


UnicastRemoteObject instances automatically export themselves to recieve remote calls, that is not the same.
You continue needing a reference to the object, given by the registry or given by other remote object.

Extending URO's main advantage is a correct implementations of hashcode, equals, for remote environments.
Regards
[ August 05, 2006: Message edited by: Oricio Ocle ]
 
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Priya

Is not clear for me how are you handling RemoteException(s) in DBAdapter.
Are you catching it and throwing the exception that is declared in the method signature ?

Thanks,

Liviu
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Priya,

your RemoteDBImpl provides network access for your DBMain, with other words this is your transport layer. If you decide to throw RemoteException(or other RMI related exceptions) in this layer you'll you application will works only with RMI - lose of flexibility.


Regards M
 
Priya Patra
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for all your comments!

Liviu,
I have a generic exception say GEx at my client end and one single point to handle all exceptions. I throw that GEx with appropriate message here and handle this.

Mihai,
If my remote interface doesn't throw RemoteException, rmic will not work. Isn't throwing a remoteexception in the Remote interface a requirement?
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Priya,

I agree with you, Remote does not work without RemoteException but can you change your transport layer(let's say from rmi to socket) without changes on the front end client ?

Regards.
 
Priya Patra
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I change RMI to Sockets, I would definitely need some changes to my front end to accomodate the specifics to sockets and modify the DBAdapter to remove the portions taking care of the RemoteException, I believe. Is that what you are trying to point out? If yes, I think this can be taken care of by handling Exception instead of RemoteException in the DBAdapter. If no, please let em know what am I missing?
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wouldn't it make more sense to just have the interface methods throw RemoteException and have the local and remote use the same interface? That's the best OOP way to do it, isn't it?
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) NEVER handle Exception, always handle specific subclasses.
2) RemoteException IS an IOException.
 
Liviu Carausu
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Priya,

Thanks for your answer. What I have understood from you is following: your front end client will use always the DB interface. The DBAdapter will "adapt" the RemoteDB interface to a DB interface by catching the exceptions that the methods from the RemoteDB are throwing ("RemoteExceptions" for example)and rethrowing the exceptions that the front end client expects("RecordNotFoundException"). In this way you can still be flexible and extend your program to use another communication layer( sockets or Corba ) ońly by writing new adapters and letting the client to deal with the DB interface...

If this is what you are doing , I agree with you, I find it a good solution.

Greetings,
Liviu
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Priya

What I try to point out is that if you choose to throw RemoteException you'll limit your application(like clients) only on RMI.
If you have a pluggable transport layer you can keep all your clients and all your servers by future extensions, it is just a question of reusability.
Imagine :
1.only RMI:
RMI Server --> RMIClients
2.general:
server -> transport -> client

And now I use the same server and client but other transport layer.

server -> transport(Socket protocol) -> client
server -> transport(RMI) -> client
server -> transport(SOAP) -> client



Regards M
 
Priya Patra
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I got your point, Mihai. Maybe I can try to make it more generic.

Liviu, You got it right. The design is as below.

Local Mode:

DB
^
|
|implements
|uses
Data <----------------------- GUIController


Remote Mode:

RemoteDBDB
^^
||
|implements|implements
wraps | wraps | uses
Data<----DBDatabaseImpl <--------- DBAdapter <----------- GUIController


The DBAdapter and the GUIController are a part of the client code here and others form a part of the network or DB layer. So if the implementation changes from RMI to some other thing, I would need to change the DBAdapter accordingly at the client side and other things will not change significantly.
[ August 08, 2006: Message edited by: Priya Patra ]
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Priya and Liviu,

you mentioned that front end clients will use always the DB interface. I have another question, how can you deal with methods getData() and getColumnName()? there are no these two methods in DB interface.

Thank you very much.

HUA
 
Is this the real life? Is this just fantasy? Is this a tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic