What are the alternatives of JMS? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago. 开发者_JS百科

Do we have any alternative for JMS?

Problem statement We have a component called Configuration Manager, which contains configuration of the application. This configuration manager is used by 4 instances of the application. Now , any time an administrator changes the configuration, it should get notified to all the instances of the application.

---

It depends on what you are trying to do.

1. For use in the same jvm you could use a BlockingQueue
2. You could have a look at Terracotta for some of their shared network maps for e.g.

---

Even after your update, your question is still not crystal clear. Given the information you provided, I see two options:

• notification. Use indeed JMS or some other notification mechanism. That depends on the technology stack: is it web applications? desktop application? does it run in an application server?
• polling. Each application has a background thread that polls the configuration manager (or the database?) for changes. When changes are detected, the whole configuration is reloaded.

For the problem of configuration refresh, I would rather go for polling (at least that's what we used for a similar requirement and it worked fine).

---

So you want to notify the 4 application instances of the change in the configuration manager.

JMS decouples the notification mechanism, so the client applications do not have to be running in order to receive the notification. The can receive the notification when they start up.

You could use JMX, EJB, RMI, a web-service call or a tuple-space such as gigaspaces, but this is slightly more tightly coupled as both client and server need to be active for the notification to be sent successfully.

This could be mitigated by building in an acknowledgment of receipt and resend functionality if necessary.
It may not be necessary, if you assume that the notification did not go through due to the application being stopped and knowledge that the application reads the configuration at start-up.
However this may not always be the cause of failure, it may be a network glitch or some other error which causes the notification to fail.
An alternative, as mentioned by ewernli would be to get the client applications to poll the config manager periodically, using any of the protocols mentioned above, changes would then be applied as soon as they are identified during the poll cycle.