This discussion is archived
7 Replies Latest reply: Jan 24, 2011 2:27 AM by 815394 RSS

UMS OpenMQ : Add Selectors and Properties Support

815394 Newbie
Currently Being Moderated
Hi everybody,

I'm facing a problem with UMS provided by OpenMQ. I would like to add some custom properties to a message, which will be used for selectors. It seems that UMS doesn't support that for the moment. Am I right ?

Has somebody already tried to implement this ?

I think i'm going to modify OpenMQ sources to add these features, if someone is interested, let me know !


Cheers,
Jerome M.
  • 1. Re: UMS OpenMQ : Add Selectors and Properties Support
    nigeldeakin Explorer
    Currently Being Moderated
    812391 wrote:
    Hi everybody,

    I'm facing a problem with UMS provided by OpenMQ. I would like to add some custom properties to a message, which will be used for selectors. It seems that UMS doesn't support that for the moment. Am I right ?
    >
    Has somebody already tried to implement this ?
    Not as far as I know. Were you thinking of adding support for properties, or support for message selectors, or both?

    Both sound potentially useful enhancements to add.

    >
    I think i'm going to modify OpenMQ sources to add these features, if someone is interested, let me know !
    The source code of the UMS war file is in src\share\java\com\sun\messaging\ums

    If you can, please let this forum (or the email forum users@mq.java.net) know how you get on!

    Nigel
  • 2. Re: UMS OpenMQ : Add Selectors and Properties Support
    815394 Newbie
    Currently Being Moderated
    Hi Nigel,

    Thank you for you reply.

    I would add support for both, as they are used together in many cases.

    For the moment, I don't realize how hard will be this task, but i'm going to try.

    I'll keep you posted !


    Jerome
  • 3. Re: UMS OpenMQ : Add Selectors and Properties Support
    815394 Newbie
    Currently Being Moderated
    Mmm i'm comparing UMS approach against ActiveMQ and Hornet Rest Interfaces. In my opinion,a Rest service would be a far better solution, easier to implement with JAX-RS API.

    What do you think about it ?

    Jerome M.
  • 4. Re: UMS OpenMQ : Add Selectors and Properties Support
    nigeldeakin Explorer
    Currently Being Moderated
    It depends on what you mean by REST. Do you mean that the HTTP requests should be stateless (i.e. not maintaining some concept of the client state on the server between requests), or that the requests should use GET rather than POST, or that more information about the data should be specified in the URL path rather than in parameters?

    Nigel
  • 5. Re: UMS OpenMQ : Add Selectors and Properties Support
    815394 Newbie
    Currently Being Moderated
    By REST, I mean that it would be based more strictly on standard HTTP methods like GET, POST, PUT.

    POST would be used for posting a message.

    POST(and not GET, as GET is idempotent) would be used for getting a message if one is available, but with another resource URL than the previous POST used to send a message.

    The QUEUE or the TOPIC would be the main resource.

    URI would be like that, for example : queue/{name}/ or topic/{name}.

    UMS doesn't follow these principles, and since it uses a servlet, there is a lot of "glue code" to handle every request and response. With JAX-RS, we just have to handle the part of the HTTP request that we need.

    Do you agree with that ?

    Edited by: Jerome M. on 21 janv. 2011 06:23
  • 6. Re: UMS OpenMQ : Add Selectors and Properties Support
    nigeldeakin Explorer
    Currently Being Moderated
    I wouldn't disagree with any of that. How were you thinking of specifying selectors and message properties?

    Your suggestion of using JAX-RS also sounds a good one.

    Nigel
  • 7. Re: UMS OpenMQ : Add Selectors and Properties Support
    815394 Newbie
    Currently Being Moderated
    Hi,

    I took a look on existing REST implementations (from ActiveMQ, HornetQ), and both use an additionnal HTTP Header to specify a selector. But there is still a lack concerning user-defined properties.

    IMHO, we could also use an Header to avoid parsing of message's body, but there is maybe another "elegant" solution. (What if several properties, delimited values ?)

    Will continue to think about it !

    Jérôme

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points