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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
