HTTP to JMS Bridge [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 years ago.

Improve this question

Overview

I'd like to expose a message queue to the internet so that client applications can communicate with some of our back-end services.

I don't want to expose the jms endpoint directly because of sercurity reasons. Also, a plain HTTP transport would obviate the need to distribute jms plugins to heterogeneous client applications (.net, java, javascript).

Research Findings

ActiveMQ

I've taken a look at ActiveMQ's "built-in" REST interface:

http://activemq.apache.org/rest.html

But in testing, I found the demo to be unreliable (i.e. "Where did my messages go?"). Also, it wasn't well documented on how to pull the demo out into a "real" implementation.

ESB

Since this is sounds like a classic "Bridge" pattern in enterprise integration patterns, I looked that the major open-source ESB/SOA integration engines:

• Spring Integration
• Mule
• ServiceMix

Of the three, the clearest piece of documentation seems to be ServiceMix's which offe开发者_StackOverflowrs a In-only message pattern, I would require both POST-ing and GET-ing messages.

Unfortunately for terms of evaluation, it seems like I would have to a deep-dive into each implementation and configuration. I realize that an out-of-the-box setup may be too much to ask, but I'd rather not learn all three just to which one fits my needs the best. So...

Questions

• Have you implemented a similar architecture? What did you use?
• Regardless of the first answer which would you suggest now?
• Which is simplest?

---

You could always check out the Apache Camel Project. It allows you to expose and route requests from Http, Web Services, etc to a JMS queue.

Although I voted for Will's answer. The servlet is really the way to go here.

---

Or you could write a servlet and do this in a couple dozen lines of code.

---

I have a similiar goal, exposing a lightweight http resource for clients. It actually acts as adapter that takes simple textmessages and puts them simply asynchronous to a queue, for later processing. My research results so far (only additions to the existing answers):

• HornetQ REST

  Good, but the calles has to know the destination name, which is undesired for my usecase. Documentation

• HJB (HTTP JMS Bridge)

  Also didn't fits my needs, beside of this the documentation is not good to understand, it is also not longer maintained. Website

I probably end up writing my own adapter, either using some thin servlet/etc. or Apache Camel.