Let's say there is an ActiveMQ as JMS broker which is fed by a master system based on java.
One of the consumers can work with MSMQ only (and we can do nothing with it)
Question Is there an easy way to forward jms text in jms messages in ActiveMQ topic to some message at MSMQ destination?
Underlying jms message contains the text of an xml file.
Depends a bit on your preferences, but a simple Camel route in ActiveMQ dispatching messages to MSMQ can do this easily - GIVEN you run your AMQ on Windows.
Camel does not really support MSMQ, but you can use some simple java lib to dispatch messages inside a java processor.
I am using IBM MQ & active mq in my application using Spring jms. I have a requirement to schedule a message for redelivery after x seconds.
I am able to achieve it in Active mq by setting the AMQ_SCHEDULED_DELAY header. This makes the message to get delivered to the queue after a specified number of seconds.
Is there anything similar in IBM MQ that I can use to achieve the above mentioned functionality ?
Any help is appreciated.
Well JMS 1.1 specification does not mention anything about delayed delivery of a message. Hence you don't have that feature in WMQ. Just released JMS 2.0 specification describes this feature.
yeah, WMQ isn't the best JMS impl for that sort of thing. Take a look at apache camel. It can provide this sort of delayed message routing.
In weblogic it is possible to create a message bridge between two JMS message queues. While configuring this bridge, a message filter can be applied so that the bridge will route messages that match the filter only.
Is it possible to achieve the same with Websphere?
Specifically I'm trying to achieve this scenario.
I have one source queue on which messages are received. Each message will have a custom JMS property set up. I would like to forward the messages on the source queue, to separate queues based on the JMS property and its value. This is easily configured in WLS using message bridges with filtering. How can I do the same in WAS?
Thanks
Savio
You need to use SIB Mediation.
The WAS info center have an example called writing a routing mediation which seems like what you need.
At the bottom of the example there is a link to what to do next which also explains how to configure WAS to use that mediation.
Without writing custom code (as per your comment on Aviram's answer), it is not possible to achieve the exact same thing, but nonetheless it is possible to achieve same effect;
You say that a 'source queue' distributes messages to other 'separate queues' according to a custom JMS property. I'm assume that you have MDBs (message driven beans) configured to process messages in these separate queues.
What you can do with WebSphere is distribute messages to these MDBs directly from the 'source queue', without having to filter/distribute them to separate queues.
This is managed by using JMS Message Selectors. You can point all your MDBs to the source queue using activation specification definitions, and for each (one for each type of message) MDB, define a JMS Message Selector that matches the ones you use in WLS. This way each message is only delivered the MDB whose filter matches the message's properties. This effectively filters/distributes messages to different MDB's as in WLS.
You may read details on configuring message selectors (during development in RAD, or at/after deploy time) at infocenter. Below is a quote to give you an idea about what it look like;
messageSelector
This attribute determines the JMS message selector
that is used to select which messages the message-driven bean
receives. For example:
JMSType='car' AND color='blue' AND weight>2500
The selector string can refer to fields in the JMS message header and
fields in the message properties. Message selectors cannot reference
message body values.
For the record, we finally ended up writing our own routing algorithm within the application to ensure that messages are sent to separate queues for each client. This way we are independent of app server implementations and the integration effort is the same across app servers, viz., adding custom queues per integrating client.
In brief, We published a JMS custom property that must be set. Using a published convention, we look up for a queue and send responses to the queue. If the property is not set, a default queue is created to route all messages. If the property is set, and the queue cannot be found an exception is raised and processing halted.
This suited our purpose. Hope it helps...
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.
I'm connecting to an IBM Websphere MQ and currently reading one message at a time using the method receive() from the object:
javax.jms.Message;
Is there a way to retrieve multiple messages from the queue in one go?
Many thanks,
G.
Depends on whether you make a distinction between "read" and "retrieve".
From a JMS perspective, no. The API will return one message per method call.
From the WMQ perspective, yes - provided the client and queue manager are both at v7 and the messages are non-persistent or being browsed. In this case you can enable read-ahead in the managed object definition or dynamically at run time. The queue manager will stream several messages off of the queue and deliver them to the application before the first one is acknowledged. For more information on this, see Using read ahead with WebSphere MQ classes for JMS.