RMI implementation

[Marcus Beale]

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

[Marlene Miller]

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.

< interface >
   Remote
     .
    /_\
     |
< interface >
     X
  ----------
  m() throws
  XException,
  RemoteException
     .
    /_\
     |
  < class >                   < class>
    XImpl     <--export--  UnicastRemoteObject
  ----------
  m() throws
  XException

public interface X extends Remote {
   Object m(Object obj) throws XException, RemoteException;
}
 
public class XImpl implements X {
   public Object m(Object obj) throws XException {
      return obj; // business/database logic goes here
   }
}
 
class SimpleClient...
   X x = null;
   try {
      switch (mode) {
         case 'l' : x = new XImpl(); break;
         case 'r' : Remote obj = Naming.lookup(URL_FOR_REMOTE_OBJECT);
                     x = (X) obj;
     ...
     Object obj2 = x.m(obj1);
 
class SimpleServer...
   try {
      Remote remoteObj = new XImpl();
      RemoteStub stub = UnicastRemoteObject.exportObject(remoteObj);
      Naming.rebind(URL_FOR_REMOTE_OBJ, stub);

[ August 23, 2004: Message edited by: Marlene Miller ]

[Marcus Beale]

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]

Thanks for your help Marcus.

[Anton Golovin]

 
 
 
if(startMode = "") {
    try {
    DBRemote data = new DataImpl_Stub(fileName);
    } catch (RemoteException remEx) { // handle }
 }
if(startMode = "local") {
    DBClient data = new DataAdapter(fileName);
}
 

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 ]

[Richard Everhart]

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]

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.

               RemoteException
                     .
                    /_\
     +---------------|------------------+
     |               |                  |
XException   ConnectException   UnmarshallException
 
 
Object[] m1() throws XException;
Object[] m2() throws XException, RemoteException;

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.

   public java.lang.Object m(java.lang.Object $param_Object_1)
throws XException, java.rmi.RemoteException

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]

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]

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