Right, but this assumes an initial invocation made by a Remoting client. The issue that we have to deal with here is that a completely unknown client (that may be written not even in Java) sends AMQP frames, and Remoting has to parse them, or at least delegate the parsing to a pluggable module. As far as I know, this is beyond of Remoting's capabilities, today.

Actually, remoting servers can identify if receiving requests from non-remoting clients and still continue to process request. Is also possible for remoting clients to send requests to non-remoting servers (just needs raw config when doing invocation). For example, have tests for http client invoker that calls on web services on the internet written with .Net and can use http server invoker as web server to Firefox browser. Also have socket client test (org.jboss.test.remoting.transport.socket.raw.RawTestClient) that makes raw socket request to socket server invoker (however, does require use of object stream instead of raw stream which will be fixed per http://jira.jboss.com/jira/browse/JBREM-597).

So I think it would be *possible* to accept and send AMQP frames via remoting, but would be so difficult with current API that if anyone tried it, they would go mad (I mean The Shining kind of mad).

The ongoing thread at http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979239#3979239 covers what would be a better approach within remoting in this regard.

 

"tom.elrod@jboss.com" wrote:

So I think it would be *possible* to accept and send AMQP frames via remoting, but would be so difficult with current API that if anyone tried it, they would go mad (I mean The Shining kind of mad).

If remoting was to introduce a layered approach as Scott has suggested, this would be possible. Since we would probably just use the lowest level directly and not worry about the higher levels.