Hi, For the rmi5 test package for learning RMI I found one solution that worked (though, of course, there may be others); though, perhaps, it is a common one. It may be so common as to not have a pattern name. Here is the client side class. The problem to be solved is that the local object which will offer a service, can come from two places: locally or remotely. I've set things up so that IndependentInterface is a top level interface, and subsidiary interfaces extend it, and these subsidiary interfaces are implemented, directly or indirectly by the local or remote service object.
The following seemed critical to bring about this RMI situation, where a local and remote object could be dealt with by the client by one reference type: 1. It was imperative that in GenImpl which throws MyException, that MyException be a run-time exception. 2. The methods in GenImpl and G have identical signatures, including for exceptions: they each only throw MyException.
Basically, there were two design ideas I have tried out so far. 1. Where the local service and the remote service objects would extend from the same abstract class, thus enabling the client to 1a. use one reference for either type 1b. store state information in a common place (the abstract instance variables) This plan would work if there was no restriction on the type of exceptions the interfaces could throw. 2. Where the local service and the remote service are related by a common parent interface. Again, this allows the client to use one reference to operate on two different types of objects. But, it doesn't allow the storage of state information (without making up new objects). These were two of the design ideas I considered for handling local and remote objects on the client side. Do you all know of any others, or is this topic not complex enough for there to be any other competing design choices? Thanks, Javini Javono [ January 25, 2004: Message edited by: Javini Javono ]
Joined: Dec 03, 2003
Hi, I've re-worked my question to be a little smaller in size (I am not overly comfortable understanding diagrams yet, and because I want to become more conversant in using them, is one reason I rephrase my question). Question: Is the design which I am about to diagram pretty standard in its usage? Does this design have a pattern name or is it too common to have a pattern name? I am not asking whether the design will work or not (i.e., is it actually feasible-- though I think it most probably is--since I'll find that out when I implement it). This design addresses the client-side. The client is getting a service object, and regardless of whether this service object is networked or non-networked, the client wants to refer to the same reference type which in this case is IndependentInterface. At this web site is an overview figure of rmi5: http://www.geocities.com/eosrubiginosa The idea is that the client will declare g1 as an IndependentInterface type and then assign it in one of two ways:
For the following text-diagram, any reference type with "Interface" in its name is a Java interface. Otherwise, it is a class.
GenImpl implements the following interfaces: Remote, Serializable. where MyException extends RuntimeException, but I may have made an error above by saying that it must extend RuntimeException instead of Exception (I'll look into that again). The methods signatures, except for the exceptions they throw, are identical in the following interfaces and classes: all of the above (i.e., G, CommonInterface, IndependentInterface, GenRemoteInterface, and GenImpl). So, conceptually, to mitigate between the two implementations, G and GenImpl which throw a non-intersection set of exceptions, you create IndependentInterface which encompasses both, different sets. The client code to catch exceptions handles the individual exceptions thrown from IndependentInterface, even though if this reference type refers to a G class, there never will be a RemoteException thrown, and likewise, if this reference type refers to a GenImpl class, there never can be a MyException.
However,it just occurred to me that since G and GenImpl do the same things, then it would make sense that G and GenImpl should both share the throwing of MyException, but I won't change the diagram above until I test the toy server/client code. Thanks, Javini Javono