"ovidiu.feodorov(a)jboss.com" wrote : | From an API perspective, client to server invocations (synchronous and asynchronous) and server to client callback (synchronous and asynchronous) is all we need. Remoting is very close to that, and I will soon publish a wiki document with suggested API amendments. But this is not the problem. The problem is that we don't need to mess around with virtual sockets to get bi-directionality. A TCP connection is inherently bi-directional. You write stuff at this end and it comes out at the other end. You write stuff at the other end and it comes out at this end. Remoting should take advantage of that in the simplest way possible. Write a different transport for that, call it "bidirectional" or "nebuchadnezzar", doesn't matter, and Messaging will use it. | +1. A bidirectional transport core abstraction is what I have been suggesting from the beginning. It just make more sense, and prevent us having to jump though fiery hoops (callback servers, virtual sockets) to get a simple(ish) job done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979595#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...