geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bordet, Simone" <simone.bor...@hp.com>
Subject RE: Remoting Update
Date Tue, 25 Nov 2003 12:29:50 GMT
Hi Hiram,

(hey, are you Italian as well ? I read Remigio Chirino somewhere: a typo ?)

> I like the queuing idea (coming from a jms background)... but 
> it would still be nice to push to the client if the protocol supports it.

The more I think about it, the more I don't see any big benefit by having a server-initiated
push approach wrt a client-initiated push approach (the JSR 160 one). And the latter seems
simpler to me.
But if there are real benefits, JSR 160 allows you to plugin whatever mechanism you want.

> Good points...  how would a protocol layer inform the jsr 160 
> layer that a listener needs to get gced??

In RMI it's sufficient to implement an interface, java.rmi.server.Unreferenced, and it will
be called by the RMI runtime when the object is DGC'ed.
A remoting framework can do a similar thing.

> Sounds good to me..   How can I get started creating 160 clients and 
> furthermore, how can I plug our remoting protocol into 160?

In MX4J you have what some facility needed to create a custom provider for JSR 160; check
the following classes:

mx4j.tools.remote.Abstract*
mx4j.remote.Abstract*
mx4j.remote.ConnectionResolver

These are the main ones to implement the connection stuff; while:

mx4j.remote.RemoteNotification[Client|Server]Handler

are the main one for notifications.

There are already 2 implementation of custom providers based on these classes: local and soap.

The JSR 160 spec is the reference of course. If you want a crash course, read the online MX4J
docs: http://mx4j.sf.net/docs

Cheers

Simon

Mime
View raw message