I am looking options to implement feature like Active MQ message groups in my application. This application is based on Spring and uses Websphere MQ as JMS provider. I cannot change JMS provider to ActiveMQ due to client constraints.
Use Case : Messages arrive in bulks on queue 1 where they are picked by listener and split into chunks and en-queued to the queue 2. Queue 2 has a single threaded listener which processes messages one after another but this behavior is leading to performance issues where there are too many messages on Queue 2. Also since bulk can have some related messages i.e. Object Create and Object Update, simply having parallel consumers wont solve the problem. As messages need to be grouped based on order Id (or some other)attribute and then this group needs to be processed by exclusive consumer.
I cant find any feature in MQ or Spring JMS to implement this unlike Message Groups provided by Active MQ.
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 use JMS (Java Message Service API) in my java application to work with queues/topics residing on websphere MQ. I am looking for a tool/support pac which can show me all MQ Messages being called e.g. when I do queueConnectionFactory.createConnection(), it would have resulted into MQCONN/MQCONNX call, so I need to see what excatly is being passed. So basically during my entire JMS based interaction, I want to see all MQ messages which are being passed to. Is it possible?
if you are using websphere, you can turn on tracing by going to WAS console and tracing service to enable jms logging.
Trace tells you what APIs are being called. To a good extent trace helps. But beyond that call IBM help.
If you are using JMS MQ client mode connection it is possible to run send/receive exits on the MQ SVRCONN channel to log the client MQI and message flows. The free IBM SupportPac MA0Z has this capability. This technique is not possible with a binding mode connection because there is no MQ channel involved.
Want to know how to create physical queue in JMS at run time.
when I search for this I got Creating JMS Queues at runtime
But when I read http://activemq.apache.org/how-do-i-create-new-destinations.html I come to know queue which mention in Creating JMS Queues at runtime is not creating any physical queue at server side.
Please correct me if I m wrong. If any one know to create physical queue at run time please replay.
Thanks in advance.
The creation of "normal" queues is not adressed by the JMS standard. Depending on what you want to do there are two approaches:
use temporary queues -> however they have many restrictions, most commonly they are used forrequest-reply scenarios
use the API of the JMS provider - however your solution will be depending on this specific provider then
The JMS standard only addresses sending and receiving data from objects like queues and topics. Creation of JMS artefacts is vendor specific and most often requires using:
1)specific vendor APIs (not JMS)
2)command/admin messages aimed at the JMS server (command agents on activemq)
3)JMX API
I have used JMX method, which is the most powerful, but also the most work.
JMX Method for activemq (version 5.0+)
a) JMS Server Setup
1) Enable JMX in activemq startup scripts and activemq.xml files
2) If you are authenticating to to the server, make sure your user has admin privileges setup in activemq.xml (see http://activemq.apache.org/security.html)
3)restart activemq server
b) Your Client Code
1) create an instance of org.apache.activemq.broker.jmx.BrokerViewMBean (you will need to connect with some JMX connectivity code which is a bit messy)
2) use its addQueue method. This will create a queue on the server
(The process is similar for hornetq but since you mentioned Activemq I have omitted hornetq details here.)
I have used this method myself and it works.
An alternative is to use Command Agents in Activemq, but I have no personal experience with these. These are special messages contain admin commands and may do what you want as well.
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.