3 Replies Latest reply on Oct 25, 2006 2:06 PM by Galder Zamarreño

    Remoting - Ability to send unformatted data

    Ovidiu Feodorov Master

      This is required to support AMQP.

      Tom Elrod wrote:

      It is possible to send and receive raw payload data using remoting where is not wrapped in the remoting InvocationRequest/InvocationResponse using configuration per request.


      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.

      More on this:

      Tim wrote:

      We should bear in mind, that at some point (not too long) we probably need to support the AMQP protocol. The AMQP protocol defines a full wire format protocol down to the last byte. Including the wireformat of the multiplex, heartbeats etc.
      I don't see how we would get that to work with remoting. So we would have to do major work then _anyway_.


      Some other (valuable) musings:

      genman wrote:

      In my opinion, it's quicker (and oddly pleasant) to craft something out of a formal specification, than to work on your own protocol. How does it go? "Bad artists copy. Great artists steal."


      Right. We didn't think to do it otherwise :)

      genman wrote:

      You need a framing protocol, and I would get to work implementing AMQP right away. Then later, or simultaneously, abstract AMQP into one of the JBoss remoting system.


      That sounds to me like a suggestion to "do it quick and dirty now and integrate later".


      The discussion is open.


        • 1. Re: Remoting - Ability to send unformatted data
          Tom Elrod Master

           


          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.



          • 2. Re: Remoting - Ability to send unformatted data
            Tim Fox Master

             

            "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.

            • 3. Re: Remoting - Ability to send unformatted data
              Galder Zamarreño Master

              +1 on http://jira.jboss.com/jira/browse/JBREM-597
              +1 on NIO

              NIO is a b1tch to implement but definitely worth it in this case. Thread per client would not scale. I'd recommend you have a look at the implementation in JGroups, that should ease the process.