In other queue managers it is possible to setup a bridge between a queue to a topic so that publishers and subscribers does not need to know that they are using a topic:
Example in TIBCO EMS
create Bridge source=queue:QName
target=topic:TName
create Bridge
source=topic:TName target=queue:QName
How do I do this in WMQ?
See WebSphere MQ V7.0 Features and Enhancements page 47, it mentions the use of Alias queues and administrative subscriptions
WebSphere MQ V7.0 introduces an
extension to the alias queue object
that allows it to be resolved to the
new topic object. This is useful for
migrating point-to-point messaging
applications to the Publish/Subscribe
model. A traditional point-to-point
application that puts messages into
WebSphere MQ can operate as a
publisher without any code changes by
utilizing an alias queue that resolves
to a topic object. This is implemented
administratively by defining a topic
object that maps to an appropriate
topic string on which the messages are
to be published. The original local
queue is deleted and replaced by an
alias queue of the same name that
resolves to the topic object. Also
note that a point-to-point application
that gets messages from WebSphere MQ
can operate as a subscriber without
any code changes by defining an
administrative subscription to a
topic.
Example 9.3 on page 220 shows how to setup a administrative subscription from a Topic to a destination queue
DEFINE SUB(SUB.RETAIL.CAT) TOPICOBJ(MATT.RETAIL.CAT) DESTCLAS(MANAGED)
DEFINE SUB(SUB.MATTRETCAT) TOPICSTR(‘matt/retail/cat’) DESTCLAS(MANAGED)
DEFINE SUB(SUB.PROVCAT) TOPICSTR(‘matt/retail/cat’) DEST(SUB.PROVCAT.DESTQ)
Related
I'm using ActiveMQ Artemis messaging system, and I'm testing my setup with STOMP (stomp.py).
I created an "address" on Artemis called Site.SOF.Order.Fulfillment.Submission.ActiveOmni.Topic, and attached two queues to it:
Site.SOF.Order.Fulfillment.Submission.ActiveOmni.queue (multicast)
Site.SOF.Order.Fulfillment.Submission.ActiveOmni.log.queue (multicast)
Here are the exported bindings:
<bindings>
<address-binding routing-types="ANYCAST" name="DLQ" id="2"/>
<address-binding routing-types="ANYCAST" name="ExpiryQueue" id="6"/>
<address-binding routing-types="MULTICAST" name="activemq.notifications" id="10"/>
<address-binding routing-types="MULTICAST" name="Site.SOF.Order.Fulfillment.Submission.Topic" id="92"/>
<queue-binding address="Site.SOF.Order.Fulfillment.Submission.Topic" filter-string="" name="Site.SOF.Order.Fulfillment.Submission.log.Queue" id="97" routing-type="MULTICAST"/>
<queue-binding address="DLQ" filter-string="" name="DLQ" id="4" routing-type="ANYCAST"/>
<queue-binding address="ExpiryQueue" filter-string="" name="ExpiryQueue" id="8" routing-type="ANYCAST"/>
<queue-binding address="Site.SOF.Order.Fulfillment.Submission.Topic" filter-string="" name="Site.SOF.Order.Fulfillment.Submission.ActiveOmni.Queue" id="94" routing-type="MULTICAST"/>
</bindings>
I created a user with access to Site.*
So how do I access the queues? For example, if I use the stomp.py command line tool like so:
> subscribe Site.SOF.Order.Fulfillment.Submission.ActiveOmni.queue
I get the error:
[username] does not have permission='CREATE_ADDRESS' on address Site.SOF.Order.Fulfillment.Submission.ActiveOmni.queue
So I try adding /queue/ to the front, as I've seen in the tutorials
> subscribe /queue/Site.SOF.Order.Fulfillment.Submission.ActiveOmni.queue
But I get the same error:
[username] does not have permission='CREATE_ADDRESS' on address /queue/Site.SOF.Order.Fulfillment.Submission.ActiveOmni.queue
I can send to the topic/address without trouble. The following results in a "hello" message appearing in both queues.
send Site.SOF.Order.Fulfillment.Submission.ActiveOmni.Topic "hello"
Is this a naming convention I'm missing? Or a way to specify topic vs queue? What am I missing here that's too obvious to be clearly documented?
Let me provide some background information first...
The ActiveMQ Artemis address model includes 3 main elements - addresses, queues, and routing types. These are low-level entities which are used to implement all the different semantics for all the different protocols and configurations the broker supports.
STOMP, by contrast, just supports ambiguous "destinations." The STOMP 1.2 specification says this about destinations:
A STOMP server is modelled as a set of destinations to which messages can be sent. The STOMP protocol treats destinations as opaque string and their syntax is server implementation specific. Additionally STOMP does not define what the delivery semantics of destinations should be. The delivery, or “message exchange”, semantics of destinations can vary from server to server and even from destination to destination. This allows servers to be creative with the semantics that they can support with STOMP.
In the core address model messages are sent to addresses and consumed from queues. Addresses and queues are named independently so the names that the core producer and consumer use can be different.
ActiveMQ Artemis supports both point-to-point and pub/sub semantics for STOMP destinations. You can read more about how to configure these semantics in the latest ActiveMQ Artemis STOMP documentation.
In the STOMP point-to-point use-case a message is sent to a destination and consumed from that same destination. The name that both the STOMP producer and consumer use are the same. In order to support these semantics the broker uses a core address and a core anycast queue with the same name.
In the STOMP pub/sub use-case a client creates a subscription on a destination which it can then use to receive messages sent to that destination. The name that both the STOMP subscriber and producer use are the same. In order to support these semantics the broker uses a core address and a core multicast queue with different names. The name of the core queue is generated by the broker automatically. The subscriber can then receive the messages directly from the underlying core subscription queue.
All this stuff is done behind the scenes for STOMP clients, but it's important to understand how STOMP maps to ActiveMQ Artemis' address model so you can configure things appropriately
In your case you've configured an address with 2 multicast queues and you're trying to consume from those queues. This use-case is a mix between point-to-point and pub/sub because you have statically defined queues (i.e. not queues auto-created by the broker in response to a subscriber) but the queues are multicast. These queues are like statically configured durable subscriptions. To access the queues directly you need to use their fully-qualified queue name (i.e. FQQN) from your client. The FQQN follows the pattern of <address>::<queue> so in your case you'd use either
Site.SOF.Order.Fulfillment.Submission.ActiveOmni.Topic::Site.SOF.Order.Fulfillment.Submission.ActiveOmni.queue
or
Site.SOF.Order.Fulfillment.Submission.ActiveOmni.Topic::Site.SOF.Order.Fulfillment.Submission.ActiveOmni.log.queue
What I would like is to run a Message Driven Bean that listens onto a (Websphere MQ7) topic. I would like to deploy my application on a Websphere 8.5.5 Cluster containing two cluster members.
If a message for the topic arrives I would expect that only one of my two MDBs gets the message and process it.
IBM states that I should set identically ClientIds and Subscription Names to ensure that only one instance is able to process a message on a Topic:
http://www-01.ibm.com/support/docview.wss?uid=swg21442559
Will the second MDB receive the mentioned MQRC_SUBSCRIPTION_IN_USE Exception, or will the cluster take care that one and only one MDB in the cluster will consume the topic-message?
Maybe someone can point me to the IBM Documentation where this behaviour is defined.
To allow multiple concurrent instances of an MDB to access the same subscription on an MQ queue manager you can enable "Allow cloned durable subscriptions" in the activation spec for the MDB.
https://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/umj_pasm.html
Running like this means both instances of the MDB will start (no IN_USE errors) and each message for that single subscription will be processed by one instance of the MDB. You would use this to workload balance messages across the multiple WAS servers.
This is only true for durable subscriptions. And only when the MDB instances are connected to the same queue manager.
We all know using EJB MDB we can consume the messages through Pub/Sub or with P2P. When i saw the comparision usually according to JMS specification, Pub/Sub is using push model and P2P is using Pull model.
Is it true, can't i consume the P2P messages in MDB using push model? Should we do any configuration changes or it is purely an server providers implementation or both.
thanks
You are speaking about difference between Topic and QUeue. So, Pub/Sub it is Topic and P2P it is Queue. Implementing push or pull model depends of server and you cannot change that behavior.
The difference between Pub/Sub and P2P is how the messages are distributed. A message sent to a topic (via Pub/Sub) is distributed to every consumer. A message sent via P2P is sent to one consumer.
The MDB programming model is a push one. Whether this is implemented as push vs pull is down to how the Resource Adapter and messaging system is implemented. WebSphere MQ and the WebSphere Application Server default messaging provider are both able to push messages to the application server for both Pub/Sub and P2P.
Hi I am new to the Websphere JMS. It is bit different configuration i.e we need to create BUS first. I also seen that Connection factory has service bus reference and same service reference is given in Queue. I have following understanding till now
We have enterprise BUS to special needs. i.e BUS has control over the messages before MDB.
We can filter,alter the message in the BUS.
What is relation between Connection factory and Queue.I just seen that Connection factory has same reference of BUS.
Why we refer the same BUS name in Connection factory and Queue.
Please correct my understanding and help me in finding answers of above questions.
SIBus is what holds the messaging engine(s) which contains destinations (point-to-point or publish/subscribe) and actually dispatch messages
In the JMS Part you got the Default JMS Provider which provides you JMS resources (Connection factories, Queues, Topics) which allows you to interact with the SIBus
In the SIBus you define a Destination on a messaging engine with some type (point-to-point or publish/subscribe)
A JMS Connection Factory creates connections to the messaging engine so you can send/receive messages, this is why you need to tell it which Bus you want it to create connections to
A JMS Queue referes to a point-to-point Destination in the SIBus.
Now for your questions:
The Bus itself is not intended to modify or filter messages
Filtering can be done by using a message selector in the MDB, when the MDB attach to the destination it will provide the message selector and the messaging engine will filter messages by it.Regarding modification I am not sure
As I stated before,
ConnectionFactory is what creates connections to the messaging engine while the Queue is an abstraction to the SIB Destination. This is why you need to tell each one which Bus it is interacting with.
Why we refer the same BUS name in Connection factory and Queue.
One reason is that the buses configured in the connection factory and the queue are not necessarily the same. That is the case in a topology with buses that are interconnected using SIBus links. In that case, you can connect to a messaging engine in one bus to send messages to a destination in another bus.
I read the hornetQ documentation, confused a lot. Can someone give an exact example to create a JMS topic in hornetQ. I mean the xml configurations in hornetq-jms.xml and hornetq-configuration.xml. assume we have a topic named top and 2 subscribers named: sub1, sub2. what I get is that we should define two queues(one for each subscribers) and bind them to an address which is the topic name actually, but how the subscriber would know they should connect to which one?(They only know the topic name)
I think you are confused by the way HornetQ handles topics internaly in contrast to the way the JMS specification describes topics.
Let's start with the JMS specification. Here you have one topic, where n subscribers can listen to the messages, that will be published by a client. In JMS we talk only about the destination in singular, eg. we'll send a message to the topic, or the queue respectively.
HornetQ is a JMS Provider - a server that implements the JMS specification, so Java-clients can connect to it, and use the JMS-API. The JMS Provider might change, but the code should still work when using another JMS provider.
However, HornetQ does not distinguish internally the destinations (topic or queue), since it tries to be a generic messaging middleware. In HornetQ all topics or queues are implemented as "addresses" and "queues". When you use the HornetQ API (CoreAPI) instead of the JMS-API, you have to deal with such things. You should read the Address section in the HornetQ documentation:
In core, there is no concept of a Topic, Topic is a JMS only term.
Instead, in core, we just deal with addresses and queues.
For example, a JMS topic would be implemented by a single address to
which many queues are bound. Each queue represents a subscription of
the topic. A JMS Queue would be implemented as a single address to
which one queue is bound - that queue represents the JMS queue.
For an example how to use a topic with JMS via HornetQ, I stongly recommend the examples that come with HornetQ itself. After donwloading and extracting the hornetq archive, just go to the examples/jms/topic directory and see the readme.html for a brief overview how to implement and how to execute the example (mvn verify).