This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

standalone with RMI

 
Mike Hays
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

I've read some threads recently about creating Service interfaces that can be used in networked and standalone modes.

My GUI controller will have a reference to a Service object that could be a remote stub or a local object. Does it violate spec to use the same class for both modes? I would like to use the Remote object in standalone mode. I would not use any networking but the object I create would be a Remote (object instanceof Remote). Since my assignment says that none of the network server code may be used in standalone mode I'm worried that this might be against the spec.

The alternative I've been reading about is to create a separate RemoteService interface that extends Service. So Service would not be a Remote but its methods would throw RemoteException. Can anyone help me understand why I can't just use the one Remote object in both modes?
 
Roel De Nijs
Sheriff
Posts: 10232
129
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mike,

I implemented the alternative, because my approach needed 2 different implementations: the method implementations are different in local and rmi mode.

According to my instructions:
Keep in mind that networking must be entirely bypassed in the non-networked mode.
The ultimate question: what is meant by the word "entirely"? No use of Remote interface or just no network traffic?
As far as I know I don't know of someone using your described approach, so following this approach might be risking automatic failure.

Kind regards,
Roel
 
Mike Hays
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay, thanks. I won't risk it.
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

I implemented an old version of B&S in 2004, and I got away with it:


Still no guarantee that your spec is phrased differently or simply judged differently ...
 
Bernd Wollny
Ranch Hand
Posts: 59
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Roel,

i think Mike's second alternative would look like Roberto explained here. So, following Roberto's approach is valid and not against the specs i think. It has to be valid, because i changed my client implementation from thick to thin and did it in a very similar way to Roberto...

Regards
Bernd
 
Roel De Nijs
Sheriff
Posts: 10232
129
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bernd Wollny wrote:It has to be valid, because i changed my client implementation from thick to thin and did it in a very similar way to Roberto...
Where did I state the alternative would be invalid? I even said I implemented the alternative

Kind regards,
Roel
 
Bernd Wollny
Ranch Hand
Posts: 59
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:Where did I state the alternative would be invalid? I even said I implemented the alternative

Ohhh, to claim that was not the intention of my post. I just wanted to write down that the second approach is a valid one like you mentioned!!!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic