aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Implementaion of the interface provided by Sun to handle local and remote connections 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 "Implementaion of the interface provided by Sun to handle local and remote connections" Watch "Implementaion of the interface provided by Sun to handle local and remote connections" New topic
Author

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

Priya Patra
Greenhorn

Joined: Jul 14, 2006
Posts: 6
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!
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
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

Joined: Jul 14, 2006
Posts: 6
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?
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

... 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 ]

SCJP, OCMJD, OCMJEA
Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 158
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


Oracle Certified Master Java SE6 Developer(SCJD),
OCE JEE 6 JSP and Servlets Developer.
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

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


SCJP, SCJD, SCWCD, OCPJBCD
Priya Patra
Greenhorn

Joined: Jul 14, 2006
Posts: 6
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

Joined: Sep 18, 2003
Posts: 918

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

Joined: Jul 14, 2006
Posts: 6
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?
Justin Overton
Greenhorn

Joined: Aug 07, 2006
Posts: 2
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?
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
1) NEVER handle Exception, always handle specific subclasses.
2) RemoteException IS an IOException.


42
Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 158
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

Joined: Sep 18, 2003
Posts: 918

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

Joined: Jul 14, 2006
Posts: 6
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 ]
hua chen
Greenhorn

Joined: Aug 18, 2006
Posts: 8
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Implementaion of the interface provided by Sun to handle local and remote connections