6 Replies Latest reply on Sep 14, 2009 8:46 AM by Tim Fox

    RESTful interface for HornetQ

    Michael Neale Expert

      Hi All. I am interested in building a RESTful interface for HornetQ - I think that with RESTEasy there is a sample which uses JMS, and there are things like restms.org.

      But what I would like to hear is what peoples thoughts are how how this interface might look:
      * should it just be built on JMS, be generic
      * should it follow something like restms.org, or other "lite" standards (also be generic)
      * should it expose some of the cool stuff in hornetQ but in a restful way?

      Thoughts?

        • 1. Re: RESTful interface for HornetQ
          Tim Fox Master

          Here are my views on the subject.

          I would rather avoid modelling any REST interface on JMS.

          JMS has unnecessary complexity - e.g. in the differences between queues and topics etc. All this can be abstracted out in a significantly simpler way, by just thinking of addresses and queues.

          A jms topic then becomes an address with many queues attached to it (e.g. subscription is queue), and a JMS queue is just an address with a single queue attached to it. So we can combine publis-subsribe and point to point messaging in that way.

          Actually, this is what we've already done on our core API. There's an overview of this here http://hornetq.sourceforge.net/docs/hornetq-2.0.0.BETA5/user-manual/en/html/using-core.html

          I'd like to see the same reflected in our REST API.

          So basically we need to support

          a) Creating queues bound to a specific address (there can be more than one queue bound to address). Queues can be durable, temporary or not.

          b) deleting queues

          c) sending messages to an address

          e) consuming messages from a queue

          f) acking messages

          And we need to think about how we support message priority, transactions and failover

          • 2. Re: RESTful interface for HornetQ
            Tim Fox Master

            I'm also going to look at REST-MS in detail

            • 3. Re: RESTful interface for HornetQ
              Tim Fox Master

              Regarding all the cool extra features in hornetq and whether we should implement them on the rest api.

              My feeling is the REST API specced out on the rest-star project should be as simple as possible, since they can't assume other messaging providers will have all the fancy features.

              However that doesn't mean we can't implement them in HornetQ - it just means they will be over and above the spec.

              • 4. Re: RESTful interface for HornetQ
                Michael Neale Expert

                 

                "timfox" wrote:
                Regarding all the cool extra features in hornetq and whether we should implement them on the rest api.

                My feeling is the REST API specced out on the rest-star project should be as simple as possible, since they can't assume other messaging providers will have all the fancy features.

                However that doesn't mean we can't implement them in HornetQ - it just means they will be over and above the spec.


                Agree - if anything mostly they would be optional headers... but I guess whatever the "Rest API" turns out to be, best to go with that...

                • 5. Re: RESTful interface for HornetQ
                  Tim Fox Master

                   

                  "timfox" wrote:
                  Here are my views on the subject.

                  I would rather avoid modelling any REST interface on JMS.

                  JMS has unnecessary complexity - e.g. in the differences between queues and topics etc. All this can be abstracted out in a significantly simpler way, by just thinking of addresses and queues.

                  A jms topic then becomes an address with many queues attached to it (e.g. subscription is queue), and a JMS queue is just an address with a single queue attached to it. So we can combine publis-subsribe and point to point messaging in that way.

                  Actually, this is what we've already done on our core API. There's an overview of this here http://hornetq.sourceforge.net/docs/hornetq-2.0.0.BETA5/user-manual/en/html/using-core.html

                  I'd like to see the same reflected in our REST API.

                  So basically we need to support

                  a) Creating queues bound to a specific address (there can be more than one queue bound to address). Queues can be durable, temporary or not.

                  b) deleting queues

                  c) sending messages to an address

                  e) consuming messages from a queue

                  f) acking messages

                  And we need to think about how we support message priority, transactions and failover


                  We should also support both polling and push (i.e. Ajaxey style long live connections) styles for message delivery.

                  Just polling will be slow, since it will require a network round trip, so will be limited to network latency not throughput.

                  Another thing to support is filters (like message selectors in JMS)

                  • 6. Re: RESTful interface for HornetQ
                    Tim Fox Master

                    Here's a link to the rest-star messaging google group.

                    http://groups.google.com/group/reststar-messaging

                    I gues we should probably discuss anything that relates specifically to the res-star interface and what it's going to look like there