• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI 005

 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
reply
    Bookmark Topic Watch Topic
  • New Topic