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
