commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vinaysahil chandran <sahilvi...@yahoo.com>
Subject Re: [AltRMI] multiplexing over single connection
Date Mon, 25 Feb 2002 22:08:26 GMT
Paul,
I was aiming along the lines
of UnicastRemoteObject.exportObject(Remote obj) .

For the EventNotifier example I was trying 
to come with , 
the Subscriber exports itself
and passes the reference of it to the Server.
Subscriber:
// SubscriberInterface.java

public interface SubscriberInterface
      extends java.rmi.Remote {
  void inform(Event event) throws 
    java.rmi.RemoteException;
}


And ConcreteSubscriber does something like
ConcreteSub()
{
UnicastRemoteObject.exportObject(this);
}


So what you are proposing with PropertyChangeListeners

would also work in my scenario too since there I
would be passing the PropertyChangeListener 
objs to the server rather than a custom
Subscriber_stub.

But this was the direction I was coming from ...

comments.?

V i n a y .


--- Paul Hammant <Paul_Hammant@yahoo.com> wrote:
> Vinay,
> 
> >Paul,
> >So would the right place to export an Object 
> >from an API standpoint be :
> >
> >AltrmiFactory.exposeObject(Object o);
> >
> You mean in the context of BEEP and the layer it
> represents inside AltRMI ?
> 
> I don't quite understand what you are asking
> here....
> AltrmiFactory is a client-side class, you would not
> call anythin on it 
> to publish (exposeObject is publishig right?).
> 
> BEEP would be used to allow us to have listeners
> straddling two VMs. 
>  Consider the well understood
> PropertyChangeListener.
> 
> Server side :
> 
> interface XyzService {
>   void addListener(PropertyChangeListener pcl);
> }
> 
> Client side :
> 
> class MyClient implements PropertyChangeListener {
> 
>    XyzService xyzService;
> 
>   public MyClient() {
>     xyzService = lookup(".... // via AltRMI
>     xyzService.addListener(this);
>   }
> 
>   public void propertyChange(PropertyChangeEvent
> evt) {
>     System.out.println("Server has performed
> callback - " + evt.toString());
>   }
> 
> }
> 
> What we see there is the client reaching out to the
> server as usual 
> (lookup), but then registering itself as a suitable
> listener. 
>  Completely asynchronously, the server can call the
> applicable method on 
> the client, even if there is TCP/IP in the way.  We
> need at least two 
> channels open to do this.  One (as we have now) to
> allow the client to 
> invoke methods on the server and the second to allow
> async invokation of 
> methods on the client from the server.
> 
> - Paul
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message