• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is this RMI Interface correct?

 
Kevin Broderick
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello once again. I've now made a start on the Networking solution and while I was browsing for solutions with regards to interfacing, one design solution came to mind as the hypothetical code shows:


I want to know if there is anything wrong with this approach. The advice throughout the forms explain it by creating a service interface that throws a RemoteException and for local approach extend the service interface with one that does not throw the remote exception like this example. Why do it this way?

Also what are the advantages of not extending UnicastRemoteObject? If I decide not to extend then I have the job of having to reimplement hashcode, equals and toString. Can anyone explain?

Thank you very much

Kevin
 
Chris Hatton
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also what are the advantages of not extending UnicastRemoteObject? If I decide not to extend then I have the job of having to reimplement hashcode, equals and toString. Can anyone explain?


I’m also working on this part of the application so I might be able to answer this partly. My reason for not extending UnicastRemoteObject is that you should not be extending classes unless you are trying to construct a specialized type of that class. I don’t believe we are doing this in this case. Also it allows you to separate your business logic from your network code (amounts to the same thing really). You have to re-implement those methods because the client may pass the remote stub back to the server, in which case you need to make sure that the same instances are equivalent and also that the sub generated from a particular instance is equivalent to the instance from which it was created. RemoteObject.toStub() will be able to help you out here. It is explained in the O’Reilly Java RMI book.

I still have some questions regarding the first part of your question myself. I’ve decided to implement an adaptor to the class that implements the interface supplied. When in standalone mode I want to use this directly but the methods throw RemoteException. Does this count as using in using network code and hence automatic failure?


 
Carlos Morillo
Ranch Hand
Posts: 221
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kevin,


Regarding this topic this is one of the threads I've found very useful.


HTH,


Carlos.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kevin (and others too of course ),

Creating a LocalService isn't really necessary (I didn't do it for example). But some people don't want the RemoteException in local approach and creating this LocalService is a possible workaround. But in my opinion it depends on how you created your client: in my case my client is totally unaware of which mode it's running (local or network), so I always have to catch the RemoteException (and other business exceptions).

Extending from UnicastRemoteObject is from a design perspective not a good idea, because (like Chris already pointed out) you are not creating a specialized type of that class. You can use this class though for creating your server:More info can be found in the thread mentioned by Carlos.

Kind regards,
Roel
 
Chris Hatton
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cheers Roel, that's just the answer I wanted to hear
 
Kevin Broderick
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the help so far guys

Ok, so I have decide to do away with extending UnicastRemoteObject but does this mean now that I have to implement code for methods hashCode, equals and tostring because on reading the documentation provided by Sun they say if UnicastRemoteObject is not extended then the implementation class must then assume the responsibility for the correct semantics of the hashCode, equals, and toString methods inherited from the Object class, so that they behave appropriately for remote objects.

If you did implement them then how is it done or am I over reacting just a little too much.

Cheers
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kevin,

I implemented only the methods from my business service interface, no implementations for hashCode, equals or toString.

Kind regards,
Roel
 
Carlos Morillo
Ranch Hand
Posts: 221
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kevin,


Same here.

The contract where you have to implement equals() and hashCode() is when the classes and objects
you define are going to be used by the Collections framework.

At the most your BusinessService object will be used by your GUI through composition as an instance
variable of one of your GUI classes to book a room and to search for rooms.


HTH,


Carlos.
 
Kevin Broderick
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Guys, your as good as always
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic