Loading ...
Sorry, an error occurred while loading the content.

[ANN] HJB (HTTP JMS Bridge) 0.9.1 released

Expand Messages
  • Tim Emiola
    Hi rest-discuss, HJB , the HTTP JMS Bridge, provides a REST version of the JMS API. This API allows
    Message 1 of 6 , Nov 28, 2006
    • 0 Attachment
      Hi rest-discuss,

      HJB <http://hjb.berlios.de>, the HTTP JMS Bridge, provides a REST
      version of the JMS
      <http://java.sun.com/products/jms> API.

      This API allows programs any language with a good HTTP library to access
      **ANY** messaging systems that provide a JMS interface. E.g, PyHJB
      <http://hjb.python-hosting.com>, is a pure python JMS client. Its
      distribution includes
      demos of using python to access JBoss Messaging, Websphere MQ, SwiftMQ
      and ActiveMQ via HJB.

      HJB 0.9.0 was released last week, but HJB 0.9.1 has been released very
      quickly afterwards to fix an important bug.

      For a list of changes in the 0.9x series of releases, please look at
      the online SVN copy of the HJB ChangeLog:

      http://svn.berlios.de/wsvn/hjb/trunk/ChangeLog?op=file&rev=0&sc=0

      HJB is pretty much feature complete, in terms of its coverage of the
      JMS API. Future efforts will involve correcting some existing design
      issues, e.g,

      http://hjb.python-hosting.com/ticket/58#preview

      and further refining the REST interface.

      Tim
    • Josh Sled
      ... [...] ... Using POST to retreive messages (as there is a side-effect of doing so) isn t really a problem, though you might want to provide a URL for the
      Message 2 of 6 , Nov 28, 2006
      • 0 Attachment
        On Tue, 2006-11-28 at 10:20 +0000, Tim Emiola wrote:
        > HJB <http://hjb.berlios.de>, the HTTP JMS Bridge, provides a REST
        > version of the JMS
        [...]
        > JMS API. Future efforts will involve correcting some existing design
        > issues, e.g,
        >
        > http://hjb.python-hosting.com/ticket/58#preview
        >
        > and further refining the REST interface.

        Using POST to retreive messages (as there is a side-effect of doing so)
        isn't really a problem, though you might want to provide a URL for the
        message/resource to the POSTer so they can subsequently GET it (and get
        the concomitant benefits). Using GET for things like registering and
        starting/stopping all these things doesn't seem great, though.

        While the API here makes good use of Location headers in response to
        POSTs, it seems like there could be a more extensive use of hypermedia.
        Right now, it appears clients are going to be hard-coded to build urls
        based on this documentation, rather than through a dialog with the
        server.


        But that strikes me as true of all of these "REST" APIs ... even if they
        follow all the constraints, APIs for other software are still APIs that
        are hard-coded into clients. :/

        --
        ...jsled
        http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
      • Tim Emiola
        ... Messages are never stored by HJB - it acts a pure gateway translating requests into actions in the JMS messaging system. Once a message is retrieved, only
        Message 3 of 6 , Nov 28, 2006
        • 0 Attachment
          On 28/11/06, Josh Sled <jsled@...> wrote:
          > On Tue, 2006-11-28 at 10:20 +0000, Tim Emiola wrote:
          > > HJB <http://hjb.berlios.de>, the HTTP JMS Bridge, provides a REST
          > > version of the JMS
          > [...]
          > > JMS API. Future efforts will involve correcting some existing design
          > > issues, e.g,
          > >
          > > http://hjb.python-hosting.com/ticket/58#preview
          > >
          > > and further refining the REST interface.
          >
          > Using POST to retreive messages (as there is a side-effect of doing so)
          > isn't really a problem, though you might want to provide a URL for the
          > message/resource to the POSTer so they can subsequently GET it (and get
          > the concomitant benefits). Using GET for things like registering and
          > starting/stopping all these things doesn't seem great, though.
          >

          Messages are never stored by HJB - it acts a pure gateway translating
          requests into actions in the JMS messaging system. Once a message is
          retrieved, only the next is available so providing a GET URL is not an
          option.

          I could not see any distinct advantage in using either GET or POST for
          start and stop things. I decided to go with GET with stop/start/other
          operations, because for nearly all them, re-requesting the URL without
          any other intermediate state changes leaves 'system' in the same
          state. Although all client interaction with a messaging system is
          inherently transient, these operations 'felt' as idempotent within the
          lifetime of any given client - hence the use of GET.

          > While the API here makes good use of Location headers in response to
          > POSTs, it seems like there could be a more extensive use of hypermedia.
          > Right now, it appears clients are going to be hard-coded to build urls
          > based on this documentation, rather than through a dialog with the
          > server.
          >

          What could be done to fix this? E.g., would it be worth adding
          something similar to the /list command that shows all the possible
          sub-URLs that can be obtained on any given resource?

          E.g. At the moment, there is no action when you try to GET any of the
          actual URIs that represent JMS resources. Or maybe a further sub-url
          could be added: /commands...

          >
          > But that strikes me as true of all of these "REST" APIs ... even if they
          > follow all the constraints, APIs for other software are still APIs that
          > are hard-coded into clients. :/
          >

          > --
          > ...jsled
          > http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
          >
          >
          >
        • Jon Hanna
          ... I m confused, but how can start or stop of anything be side-effect free?
          Message 4 of 6 , Nov 28, 2006
          • 0 Attachment
            Tim Emiola wrote:
            > I could not see any distinct advantage in using either GET or POST for
            > start and stop things. I decided to go with GET with stop/start/other
            > operations, because for nearly all them, re-requesting the URL without
            > any other intermediate state changes leaves 'system' in the same
            > state. Although all client interaction with a messaging system is
            > inherently transient, these operations 'felt' as idempotent within the
            > lifetime of any given client - hence the use of GET.

            I'm confused, but how can "start" or "stop" of anything be side-effect free?
          • Mike Dierken
            Nifty. I started something like that a long time ago (http://sourceforge.net/projects/destiny/) but never kept working on it. I hope you find success with your
            Message 5 of 6 , Nov 28, 2006
            • 0 Attachment
              Nifty. I started something like that a long time ago
              (http://sourceforge.net/projects/destiny/) but never kept working on
              it. I hope you find success with your project and keep it going.

              > Messages are never stored by HJB - it acts a pure gateway translating
              > requests into actions in the JMS messaging system. Once a message is
              > retrieved, only the next is available so providing a GET URL is not an
              > option.
              How do you know that the retrieval was succesful?
              You may want to consider explicit message acknowledgement, possibly
              via DELETE where the URI contains the message id.


              >
              > I could not see any distinct advantage in using either GET or POST for
              > start and stop things. I decided to go with GET with stop/start/other
              > operations, because for nearly all them, re-requesting the URL without
              > any other intermediate state changes leaves 'system' in the same
              > state. Although all client interaction with a messaging system is
              > inherently transient, these operations 'felt' as idempotent within the
              > lifetime of any given client - hence the use of GET.
              Although start/stop may be idempotent (predictibly repeatable) they
              don't seem safe - they do change how the system will behave after that
              point.

              >
              > > While the API here makes good use of Location headers in response to
              > > POSTs, it seems like there could be a more extensive use of hypermedia.
              > > Right now, it appears clients are going to be hard-coded to build urls
              > > based on this documentation, rather than through a dialog with the
              > > server.
              > >
              >
              > What could be done to fix this? E.g., would it be worth adding
              > something similar to the /list command that shows all the possible
              > sub-URLs that can be obtained on any given resource?
              That would be very nice.
            • Mark Baker
              Right. Once again, I have to point out that the important feature of GET from this POV is not idempotence, it s safety. I wonder where this misconception came
              Message 6 of 6 , Nov 28, 2006
              • 0 Attachment
                Right. Once again, I have to point out that the important feature of
                GET from this POV is not idempotence, it's safety.

                I wonder where this misconception came from?

                Mark.

                On 11/28/06, Jon Hanna <jon@...> wrote:
                > Tim Emiola wrote:
                > > I could not see any distinct advantage in using either GET or POST for
                > > start and stop things. I decided to go with GET with stop/start/other
                > > operations, because for nearly all them, re-requesting the URL without
                > > any other intermediate state changes leaves 'system' in the same
                > > state. Although all client interaction with a messaging system is
                > > inherently transient, these operations 'felt' as idempotent within the
                > > lifetime of any given client - hence the use of GET.
                >
                > I'm confused, but how can "start" or "stop" of anything be side-effect free?
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.