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

6175Re: [rest-discuss] REST & Internal Integration

Expand Messages
  • Claude Montpetit
    May 1, 2006
      Mike Dierken a écrit :
      > Mike,
      > Sorry I haven't responded sooner... To make up for it, I wrote a really long
      > response.
      >
      > I don't have anything against JMS or messaging systems, they are great
      > tools. And just like HTTP, they work wonders when used in the right
      > situation. This thread is interesting to me because there hasn't been much
      > discussion about applying aspects of REST to a classical asynchronous
      > messaging based system.

      I've been playing with both JMS and REST recently and at first, I was
      trying to see how REST could be used instead of JMS. I came to think
      that these 2 "specifications" should not be seen as one-or-the-other.
      They are 2 different technologies that solve 2 different sets of
      problem; they can play together nicely when facilitating access to a JMS
      service is a requirement.

      In our system, we have a bunch JMS services (queue receivers and topic
      consumers). We provide custom Java client classes that clients can use
      to easily connect to the services. These talk directly to the JMS
      brokers to contact our JMS services.

      There is (well, will be) also a REST interface to the JMS services. The
      REST service allows the creation of a service request through a simple
      POST to a URI. The implementation of this REST "service" connects to the
      JMS broker, sends the corresponding message, and waits (with timeout)
      until it receives confirmation that the message was received by the JMS
      service. This confirmation of reception implies that the service request
      has created a resource and this new resource is returned to the REST
      client who can, at anytime, GET it to see the status of his orignal
      request (running, completed, cancelled, logging ...).

      So far, the JMS custom client classes are only used internally, and
      while the system has not yet been used by our clients, I expect they
      will prefer to use the REST access to the service. Even though the Java
      JMS custom classes provide finer control, REST' simplicity will most
      likely be a real advantage.

      Technically, from REST's client perspective, the launching of the
      service is synchronous: the REST server connects to the JMS service,
      waits for confirmation of reception, and returns the resource URI to the
      client. But the execution of the service request is asynchronous, and
      the REST clients can make calls on the returned URI to check the status
      of the JMS service request.



      > [...]
    • Show all 12 messages in this topic