Can anybody point out a reference on how to implement
a single consumer multiple producer in activemq? Or could give a very simple implementation.
This will be very helpful.
Thanks
Matt Raible's AppFuse project is a good skeleton project which is implemented using different libraries. You can pick the one which uses Spring and introduce ActiveMQ as Bharati Raja has explained in his blog post jms with appfuse1x.
There is no special implementation required for this. This is the core business of MessageBrokers. The only thing you need to make sure of:
If you decide to give an ID to your producers, make sure they are different from each other.. You cannot have multiple producers with the same ID. Same goes for consumers.
If you need to guarantee that a message can be consumed by only one consumer, then this is the point-to-point communication model which can be implemented using a JMS Queue in ActiveMQ.
Many producers can send messages to the same queue. Only one active consumer will receive a message from the queue.
Related
I am trying to get multiple listeners configured on same queue, but with different message selector. I am using Solace JMS provider.
The behavior is that the first loaded listener will have its selector registered and is receiving the messages.
the second listener is NOT receiving the message. And using Spring integration DSL 1.1.3
what could be wrong?
I tried with two different Queue connection factory, but could not get it working.
How can we have two Selective consumers configured ?
I think you should start from your vendor first of all and try to figure out if it supports concurrent selective consumers.
Although you have to bear in mind that with the Queue only one consumer accepts message anyway. So, if first one is able to process the message, the second one won't receive it, even with different selector.
Consider to switch to the Topic.
I am trying to understand JMS.
What is the difference between ActiveMQ and JMS
can pool the data from NON ActiveMQ with ActiveMQ plugin in Spring?
Thanks ,In advance
JMS is a specification. JMS has three main parts to it. The first is the producer, which is nothing more than a bean that submits a "message" to a JMS broker (#2) (the system that manages messages between producers and consumers). In this case, ActiveMQ is the broker. Once the broker receives a message, the consumer (#3), or Message-Driven Bean (MDB), processes the message.
If you want to work with JMS, you'll just write both your producer/consumer code using the JMS API, but behind the scenes there is a "resource adapter" that is a special ActiveMQ driver that will connect to an ActiveMQ instance and do the management for you.
Have a look at this post I made recently. I'm still trying to figure out the best way to write JMS beans, but I've got the basics down.
The accepted answer emphasizes what is the structure of JMS is. Not disagreeing just want to add to it in case anyone else wants to know. ActiveMQ could be a JMS supplier. A JMS supplier shapes the computer program system for encouraging the utilize of JMS concepts interior an application. A single node of ActiveMQ which permits clients to associate to it and utilize these informing concepts is called an "ActiveMQ Broker."
Enterprises feel this disparity with business actions such as mergers and acquisitions. This creates the need to maintain an increasingly heterogeneous collection of business applications. As your enterprise grows, so does the need to allow all of these platforms to share data. A number of architectural patterns exist today which help to solve this problem.
Some other examples of JMS providers are:
HornetQ.
RabbitMQ.
SonicMQ.
Winsows Azure Messaging
The following example shows a simple configuration of an ActiveMQ connection:
<jms:config name="JMS_Config">
<jms:active-mq-connection >
<jms:factory-configuration brokerUrl="tcp://localhost:61616" />
</jms:active-mq-connection>
</jms:config>
This post explains a detailed difference between the ActiveMQ and JMS (or maybe about the details of their specifications). Hope it clears your concepts.
I' m currently investigation the implementation of queue's or topic, based on activeMQ within our project. The setup is pretty straight forward in which we are using maven modules to seprate business logic according to the business domain. One common module allows us to assemble common logic.
simplified Example:
common module
products module
clients module
One of the requirements is that certain operations are asynchronous towards a backend (by means of a activeMQ) which in turn responds with a result message.
The second requirement is that it should be possible to horizontally scale the application by creating a new deployable artifact with only that module that needs more juice.
We are using spring 4 with of course jms and activeMQ.
On to my question. We would like to use just one queue or topic for backend connectivity. Which would mean our common module would handle jms configuration (jms factory, jms-configuration) and different types of messages will be send over that one queue/topic.
How would can I make sure that product related messages get handled by the "products" module and client related messages get handled by the "clients" module? How can I make sure only one of the "products" modules logic would handle a message if the module was deployed two times? What approach would you recommend or is this one queue/topic "nuts"?
I was myself thinking in the direction of using a topic because of the publ/subsc pattern... , or maybe queue listener acting as publisher in a observer pattern to which product- or client subscribers might subscribe to take over handling the message?
Thanks for your help.
Why using a Topic if you want just one of the "products" modules to handle one message? With Topic you'd have one message - multiple subscribers each getting the message. The Queue ensures only one consumer gets a message (point-to-point), with Topic you'd have one message dispatched to all subscribers.
Regarding the "filtering" of messages, this should be something provider specific. Looking at ActiveMQ docs I see this. So, basically each consumer should get the messages the broker, based on selector, will dispatch. I don't know the specifics, but this would be the first place I would start this investigation.
On the same idea, have a look at this discussion from the Spring forum. It is, indeed, related to Spring Integration, but it's on the same idea of message selection. On the other hand, you could consider adopting Spring Integration in your project: it's kind of an abstraction of integration patterns and fits well with everything message oriented.
Few interesting ideas from that forum post:
JmsTemplate from Spring contains a doReceive method that takes as a parameter a String as message selector
Message selectors are in the JMS spec (scroll down to "Message Properties" section)
Relevant section in the Spring Integration documentation is here
I need a messaging or event framework in my Spring project.
Basic requirements:
Single producer/sender, which will create the messages/events
Global channel/queue/etc where the producer will send messages into
Multiple components should be able to register within this channel/queue, so they can receive the messages/events
All components should be able to receive all messages - every message would be visible to all receivers, NOT just to one (first one for example). So single consumer cannot make a message to disappear and be not visible to others
Messages should be distributed across all consumers asynchronous way, so all of them can receive messages at the same time, not just each after other
What would the best fit for my needs?
I think your requirements meet the features of Spring Integration.
http://www.springsource.org/spring-integration
Spring has native support for Observer pattern (Look at Events section). Check if it meets your needs. If it doesn't then you can use Spring's JMS support + ActiveMQ.
Guava EventBus could work for you. It allows publish-subscribe-style communication between components without the need for them to explicitly know of each other. Here's a nice article explaining it further with some examples.
For me JMS and ESB seem to be very related things and I'm trying to understand how exactly they are related.
I've seen a sentence that JMS can be used as a transport for ESB - then what else except the transport should be present in such an ESB? Is JMS a simple ESB or if not, then what it lacks from the real ESB?
JMS offers a set of APIs for messaging: put a message on a queue, someone else, sometime later, perhaps geographically far away takes the message off the queue and processes it. We have decoupled in time and location of the message provider and consumer. Even if the message consumer happens to be down for a time we can keep producing messages.
JMS also offers a publish/subscribe capability where the producer puts the message to a "topic" and any interested parties can subscribe to that topic, receiving messages as and when they are produced, but for the moment focus just on the queue capabilty.
We have decoupled some aspects of the relationship between provider and consumer. However some coupling remains. First, as things stand every message is processed in the same way. Suppose we want to introduce different kinds of processing for different kinds of messages:
if ( message.customer.type == Platinum )
do something special
Obviously we can write code like that, but an alternative would be to have a messaging system that can send different messages to different places we set up three queues:
Request Queue, the producer(s) puts their requests here
Platinum Queue, platinum consumer processing reads from here
Standard Queue, a standard consumer reads messages from here
And then all we need is a little bit of cleverness in the queue system itself to transfer then messsage from the Request Queue to the Platinum Queue or Standard Queue.
So this is a Content-Based Routing capability, and is something that an ESB provides. Note that the ESB uses the fundamental Queueing capabilities offered by JMS.
A second kind of couppling is that the consumer and producer must agree about the message format. In simple cases that's fine. But when you start to have many producers all putting message to the same queue you start to hit versioning problems. New message formats are introduced but you don't want to change all the existing providers.
Request Version 1 Queue Existing providers write here
Request Version 2 Queue New provider write here, New Consumer Reads here
And the ESB picks up the Version 1 Queue messages and transforms them into Version 2 messages and puts them onto the Version 2 queue.
Message transformation is another possible ESB capability.
Have a look at ESB products, see what they can do. As I work for IBM, I'm most familiar with WebSphere ESB
I would say ESB is like a facade into a number of protocals....JMS being one of them.
An addition to the above list is the latest Open Source ESB - UltraESB
JMS is not well suited for the integration of REST services, File systems, S/FTP, Email, Hessian, SOAP etc. which are better handled with an ESB that supports these types natively. For example, if you have a process that dumps a CSV file of 500MB at midnight, and you want another system to pickup the file, parse CSV and import into a database, this can easily be accomplished by an ESB - whereas a solution with just JMS will be bad. Similarly, integration of REST services, with load balancing/failover to multiple backend instances can be done better with an ESB supporting HTTP/S natively.
This Transformation does not happen automatically. You need to configure the mapping or write transformation service
Look at https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_SOA_Platform/4.2/html/SOA_ESB_Message_Transformation_Guide/ch02s03.html
Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com
ESB offers integration with a lot of different protocols in addition to JMS.
Most use JMS behind the scenes to transfer, stor and move messages. One such solution OpenESB, uses XML format messages.
There are open source ESB which you could checkout -
OpenESB
Apache Camel
MuleESB
WSO2 ESB
JMS implementation like ActiveMQ come with Camel inbuilt into them.
JMS is a protocol for communicating with an underlying messaging layer. ESB operates at a higher level, offering integration with multiple technologies and protocols, one of which would be JMS, in a uniform way that makes management of complex flows much simpler.
There are JMS message brokers , that you can easily configure with ESB. https://docs.wso2.com/display/ESB470/JMS+Transport
JMS and ESB both provide a way of communication between different applications. But the context for JMS and ESB are different. JMS is for simple need. JMS is implemented by JMS Provider. It is Java specific.
Examples of JMS Providers are: Apache Active MQ, IBM MQ, HornetQ etc.
ESB is for complex need. ESB is a component in EAI providing communication facility to various applications. It is generic & not specific to Java. JMS is one of the supported protocols.
Examples of ESB provider are: MuleESB, Apache Camel, OpenESB
Use Case: It may be an overhead to use ESB, if all our communicating applications are in Java and are using the same message format. Here JMS may be sufficient.