"david.lloyd(a)jboss.com" wrote : | The proxy would have to know some transport information. If it does not, there is no way for the client (or whoever reads the proxy from JNDI) to know where it's connecting back to, or how. | A URL, or a set of URLs in the case of clustering, would be transport independent, yet sufficient information to contact the server (at least for some transports). "david.lloyd(a)jboss.com" wrote : | That said, the connection information (at least, as pertains to Remoting 3) could amount to "whatever connection this proxy came in on", and that'd probably be OK. | I've started thread "Remoting 3 protocol SPI" on the Remoting design forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267127#...) for related Remoting specific discussion. "david.lloyd(a)jboss.com" wrote : | However, I don't see any sensible way we can get around having separate proxy implementations for IIOP/JRMP/Remoting/whatever. | To a certain extent, there could be a general purpose "client" API that let's you just plug in a URL. Something like | interface ProtocolBuilder { | static Protocol getProtocol(String protocol); | } | | interface Protocol { | static getClient(URL url, Map config); | } | | interface Client { | Object invoke(Object invocation, Map metadata); | void close(); | } | You'd have to register each protocol with ProtocolBuilder. I don't know enough about IIOP to know if it would work there, but I'm pretty sure it's general enough for, say, Remoting 2 and Remoting 3. And isn't that the whole world? :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267143#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...