File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RMI explination 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 "RMI explination" Watch "RMI explination" New topic
Author

RMI explination

Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
hi guys:
I am newbie to RMI, and I appreciate if any one can explain to me how can I solve the following issue:
My project is Bodgitt & Scrapper. I have to implements a DBMain interface, which conrols the IO operations to the database. The interface is implements by a class called Data. None of the interface methods throw IOException. This interface is the backbone of the data access layer. In my view layer, I forward all requests from the client to the Data class.
Now I want to implements RMI support. How can I make the Data class a remote object, so that a client can invoke its methods remotely? To implement the Remote interface, all methods must throw RemoteException, which violates the contract of DBMain interface, becuase RemoteException is a checked Exception.
My initial thought about this is to create a new interface similar to DBMain, but all of its methods throw IOException, then use composition and forwarding using an instance of the Data class.
I don't like the idea becuase it is redundant of code.
Can someone explain to me different approach?
Thanks


SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Hanna,


My initial thought about this is to create a new interface similar to DBMain


Couldn't it be a superclass? Remember that the subclass does not need to throw all of the excpetions of its ancestors.....

Cheers,

Jon


SCJD, SCEA
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Hanna,

Sorry, I'm not going to describe another way to solve the problem because the solution you describe is probably the simplest and best way to do it. What you described is simply creating an RMI Adapter for the DBMain interface. There is no duplication of any implementation code, only delegation.


kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
hi Jon:
I am not sure if I understand what you said by "couldn't it be a super class?" Did you mean that the new interface could be a subinterface of the DBMain interface?
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Hanna,

Yes, that is what I meant . I like this solution as it lets the cient treat the local Data or the RMI Data (or serialized data for that matter, as it throws an IOException) as an instance of this superinterface.

Jon
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
hi Jon:
My new interface(network adaptor) cannot extends DBMain interface and overridee the methods to throw a RemoteException, also I cannot define new methods with the same signature.
Am i missing somethign here?
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Hanna,

You are right - you can't throw new exceptions from a subinterface of DBMain (the compiler would stop you), rather DBMain would need to extend the new interface. i.e. define a new interface which is the same as DBMain but throwing IOException or RemoteException, and declare DBMain as a subinterface.

This means that the client can treat all instances of Data as an instance of this new interface and execute all of the methods it defines without needing to know which transport mechanism was used (RMI, sockets or by a local connection)

Hope this helps ....

Jon
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
thanks Jon. It is more clear now
Phil Harron
Greenhorn

Joined: Jun 21, 2002
Posts: 29
Hi Hannah/Jon

I too am having the same issues with my Urlybird project. Just to confirm what you are saying is to create a new Interface with all the methods from DBMain which throw RemoteExceptions (and any other exceptions which DBMain throws).

The only change to make in DBMain then, is to extend the new interface?

Is this an Adapter pattern?

Thanks
Phil


SCJP 1.4<br />SCJD (Ongoing)
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Originally posted by Jon Entwistle:
You are right - you can't throw new exceptions from a subinterface of DBMain (the compiler would stop you), rather DBMain would need to extend the new interface. i.e. define a new interface which is the same as DBMain but throwing IOException or RemoteException, and declare DBMain as a subinterface.


Aren't we changing the definition of SUN's DBMain interface by doing this?...From the instructions, SUN's DBMain interface does not extend anything. I am thinking about the automated software checks that the examiner uses to check the code definitions. :roll:
Phil Harron
Greenhorn

Joined: Jun 21, 2002
Posts: 29
That's something I was concerned about as well. Has anyone any thoughts on this?
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Originally posted by Phil Harron:
Just to confirm what you are saying is to create a new Interface with all the methods from DBMain which throw RemoteExceptions (and any other exceptions which DBMain throws).

The only change to make in DBMain then, is to extend the new interface?

Is this an Adapter pattern?


It doesn't sound like an Adapter pattern to me, though it does resemble class adapter pattern a bit.I am also curious to know what pattern is this?

http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/adapter.htm
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Phil/Vishwa,

You are right - you cannot alter the method signature of the interface of the sun supplied interface, Sun's tests would almost certainly fail.

What I am suggesting is that you create a new interface with the same method signature as that supplied by Sun, but throwing extra exceptions and declaring it as a superinterface. Declaring this inheritance relationship will not change the signature of the methods in the Sun supplied interface in any way and so the tests would not fail.

Of course another way around this is to create a proxy or adapter class to throw the extra exceptions.....

Hope this clears it up a bit ....

Jon
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Thanks Jon,
That cleared up the ambiguity. If SUN were not so rigid about the interface/method signatures, probably we could have used this idea.
This seems like a good pattern for adding new exceptions.(a kind of an adapter pattern). I think this pattern would have been used by somebody else outside this assignment and would have had a name.
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Vishwa,

I don't think I am explaining myself to well

What I am saying is that there are at least two options to solve the problem of additional exceptions.

1 - Use the proxy or adapter pattern to wrap the interface, and throwing the extra exceptions as needed.

2 - create a new interface with exactly the same methods as the Sun supplied interface, but throwing the extra exception needed (RemoteException or IOException). You would then need to declare taht the Sun supplied interface is a subinterface of this new interface. Note that you are not changing the method signature of the Sun supplied interface in any way by doing this!

Both approaches still require you to implement the Sun supplied interface in your data class (although in the second approach this is now explicitly declared as a subinterface). Neither approach would risk making Sun's test scripts failing (you would need to do something else to do that )

- Jon
[ June 03, 2004: Message edited by: Jon Entwistle ]
Phil Harron
Greenhorn

Joined: Jun 21, 2002
Posts: 29
Thanks Jon,

Sorry but can you clear one thing up for me...

You would then need to declare taht the Sun supplied interface is a subinterface of this new interface.


What exactly do you mean by declaring the Sun supplied interface is a subinterface ?

Thanks
Phil
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
hi Jon:
I really appreciate you taking the time to ansewer this.
In the second approch that you descriped.

create a new interface with exactly the same methods as the Sun supplied interface, but throwing the extra exception needed (RemoteException or IOException). You would then need to declare taht the Sun supplied interface is a subinterface of this new interface.

In this design, the SUN supplied interface simply override the methods created in the new interface. When it comes to implement a concrete class of the SUN supplied interface, we still cannot throw the extra exceptions, becuase they already overriden by the subinterface.
In this situation we still have to implement two classes. One that implement the new interface, and the other implement the SUN supplied interface.
Correct me if I am wrong.
for example:

interface DBMain extends Network
{public void read()throw RecordNotFoundException;}

interface Network
{public void read()throw IOException;}

class Data implements DBMain
{public void read() //here we cannot throw IOException}
[ June 03, 2004: Message edited by: Hanna Habashy ]
Phil Harron
Greenhorn

Joined: Jun 21, 2002
Posts: 29
Thanks Jon,

Sorry but can you clear one thing up for me...

You would then need to declare taht the Sun supplied interface is a subinterface of this new interface.


What exactly do you mean by declaring the Sun supplied interface is a subinterface ?

Thanks
Phil
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Phil,

Here is the outline of how to do it:





Jon
[ June 03, 2004: Message edited by: Jon Entwistle ]
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Jon,
I understand the same way as Hanna pointed above.

interface OurInterface {
String[] read(int recNo) throws RecordNotFoundException, RemoteException;
}

interface DBMain extends OurInterface {
String[] read(int recNo) throws RecordNotFoundException;
}


class Data implements DBMain {
String[] read(int recNo) throws RecordNotFoundException {

}
}

The interface used by the client programs would be OurInterface.This could be used for both local and network mode.

I understand that you are not changing the method signatures inside the DBMain interface.But I am talking about the definition of DBMain itself! SUN's DBMain interface given in the instructions does not extend from anything, While the DBMain interface that you are talking about extends from OurInterface as in the example above!
I was wondering if we are allowed to do this as the examiner is likely to use an automated code checking program to go thru our code first.
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Jon,
Looks like yourself,myself and Hanna are talking about the same thing.
The question is......is the approach acceptable by SUN?
We are not changing the method definitions, but aren't we changing the SUN's interface definition?
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118

When it comes to implement a concrete class of the SUN supplied interface, we still cannot throw the extra exceptions, becuase they already overriden by the subinterface.


You should only implement one Data class which implements the interface given by Sun.

The trick is that this Data class has an IS-A relationship with this Sun supplied interface and also has an IS-A relationship with your new interface too.

Imagine that the client is waiting for an instance of this new interface:

If the client recieves a local copy which implements the Sun supplied interface, it will be happy (it is still IS-A instance of your new interface).

For RMI you will need some Remote object to pass to the client via RMI. If this object also implements your new interface (say by wrapping your Data instance), then the client will still be happy as it also IS-A instance of your new interface also.

The benefit of this is that the client can use polymorphism to execute the methods of your interface without carrying which transport mechanism was used to obtain it.

Does this make sense?? It is very tricky I know....

Jon
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Vishwa,

but aren't we changing the SUN's interface definition?

Heck, I would go as far as to say you could bet the ranch that you would not be

By declaring an extends relationship in this case you are indicating a semantic relationship, not altering the method signature.

Cheers,

Jon
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
hi Jon:
Thanks alot for your reply. Yes it makes more sense now. I agree with you that extending another interface won't change the signature.
thanks again
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI explination