Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

RMI implementation

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marlene,


(As one more thought experiment, we could toss out CD and export CS. Then CS would actually be a remote object.)



Awsome idea!

However I don't think it would work for my code as is. I have a little bit of additional logic in CD, mainly related to starting and stopping the server. I wonder if there would be anyway to move that to CS without abusing the class abstract. Maybe move it to another class, but that would probably end up looking alot like CD. Mmmm.. food for thought.
You would have to be careful not to initialize any RMI objects in local mode.

PS. Before anyone decides to move to a bussiness server (3 tier approach) read this thread:
2 tier vs 3 tier
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcus.

>> However I don't think it would work for my code as is.

I expect for many people, the examples here would have to be modified to meet the other constraints of their assignment.

----
I tried exporting. I learned that the exported object must implement Remote. So in local mode, the client would be using a "remote object".

Example 6. Exporting the remote object

The interface is called X. XImpl does not extend UnicastRemoteObject. In local mode, the client uses XImpl. In remote mode, the server uses XImpl.


[ August 23, 2004: Message edited by: Marlene Miller ]
 
Marcus Beale
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marlene,

That design looks pretty slick. If anyone uses it, post a message here and let us know how it goes.


You would have to be careful not to initialize any RMI objects in local mode.



I meant to make sure the design didn't initalize the RMI registry or something that would cause networking to occur. I don't think using a "Remote Object" would be an issue. (It better not be because I already turned in my asignment and I was doing that in the original design!) I'm guessing to test this project Sun will replace the networking libraries in java with some empty classes that simply throw exceptions and log network acccess attempts to a file. If any network attemtps are found when running your program in local mode, you get an automatic failure.
[ August 23, 2004: Message edited by: Marcus Beale ]
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your help Marcus.
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I apologize for the raw nature of the code, but this is probably the best way to visualize the design.
[ August 23, 2004: Message edited by: Anton Golovin ]
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, this is a great discussion, and very timely for me!

Marlene, my design just so happened to match your example 1 (RemoteX extends X) exactly. I've implemented the local version, where XImpl is used by the client and I'm now trying to get along with the remote part. However, I'm having trouble getting the code I've already implemented to compile. I thought I could have, in your terms, XException extend RemoteException, this way client code could directly use XImpl and only have to catch XException. Now I find that all code that simply catches XExeption causes errors because RemoteException isn't caught as well. Is this to be expected in this design? Even after creating and compiling your example I get the same compilation errors. Is your example 3 (wrap RemoteX, hide RemoteException) the only solution to this problem?

Rich

p.s. After taking another look at example 3 makes me think that only this solution will hide the RemoteException.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rich.

>> I thought I could have, in your terms, XException extend RemoteException, this way client code could directly use XImpl and only have to catch XException.

Actually, for me XException represents one or more application (business or database) exceptions, possibly but not necessarily a superclass of business and database exceptions, anything but RemoteException. I could have said, X1Exception, ..., XnException. But it�s not important. It�s just a raw idea. It�s there to play with and modify. You decided to make it extend RemoteException.

>> Now I find that all code that simply catches XExeption causes errors because RemoteException isn't caught as well. Is this to be expected in this design?

Yes, it is to be expected.

We know for sure that methods of the remote interface must throw RemoteException. Now, why can�t they throw your XException instead? If you look at the API for RemoteException, you will see 19 subclasses. If you declare a method to throw XException, your method cannot throw the other 19 exceptions.

On the server side, your methods wouldn�t throw the other exceptions, because they are your methods, not part of the RMI Runtime. But on the client side, the stub needs to be able to throw those other methods, not just XException.

>> Is your example 3 (wrap RemoteX, hide RemoteException) the only solution to this problem?

It�s the only way I could think of to hide the RemoteException. While coming up with these examples, I was motivated to try to hide the RemoteException. I was also motivated to find simple solutions.

I presented 3 examples. Then I added a 4th example. Then Marcus showed us his solution. Then I added a 5th example. #3 is the only one that hides the RemoteException.

I am not so sure it's important to try to hide that RemoteException (although I did take the opposite view when talking to Marcus above).

>> After taking another look at example 3 makes me think that only this solution will hide the RemoteException.

Yes, I think so.

If you use the �keep option with rmic, you will get the source file for the stub. You will see that the stub implements your methods.

So the object you get from Naming.lookup throws the methods of the remote interface. So that object throws RemoteException. If you want to hide the RemoteException, it seems to me you must wrap the thing you get from Naming.lookup.

----

I am so happy to know my examples made some sense to you and maybe even helped some. Thanks for considering my thoughts.

Marlene
[ August 27, 2004: Message edited by: Marlene Miller ]
 
Richard Everhart
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I am not so sure it's important to try to hide that RemoteException (although I did take the opposite view when talking to Marcus above).



I didn't take the time to read your comments to Marcus, but the reason I want to hide the RemoteException is that, ideally, other types of mechanisms could be implemented to facilitate client/server communications, like sockets or something else. My feeling is that client classes should not know the implementations details of how it is communcating to the server and exposing the RemoteException would do just that.


I am so happy to know my examples made some sense to you and maybe even helped some. Thanks for considering my thoughts.



Your ideas are most invaluable, and for me, could not have been available at a better time. Thanks again!

Rich
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>> the reason I want to hide the RemoteException is that, ideally, other types of mechanisms could be implemented to facilitate client/server communications, like sockets or something else. My feeling is that client classes should not know the implementations details of how it is communcating to the server and exposing the RemoteException would do just that.

A socket implementation. To me, that's a very good reason. Thank you.
 
Mo-om! You're embarassing me! Can you just read a tiny ad like a normal person?
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic