Virtual and Composite Destinations with Apache ActiveMQ

Apache ActiveMQ / FUSE Message Broker has a feature called Virtual Destinations that are logical destinations (queues or topics) mapped to one or more physical destinations.

There are many benefits for using Virtual Destinations with ActiveMQ but basically you can forward messages from one JMS destination to many destinations (mixing queues and topics if you want), route messages to target destinations based on message headers (a.k.a broker-based message routing) and create highly-available load-balanced durable subscribers.



As an example, looking in the diagram above, you can have a Virtual Destination called q1, where applications will send messages to as they do to any other regular queue, and then the message will get propagated to a real physical queue called q1, to a real queue physical queue called Q2 and also to a topic called T1.

The example above is called Composite Destinations and the idea behind it is to map a Virtual Destinations to a hard-wired collection of physical destinations. From the JMS client application perspective there is nothing you'll need to change since all the configuration happens at the broker level.

So, let's look on what need to be done to work with Virtual and Composite Destinations with ActiveMQ.


The diagram above represents the idea of having producer P sending messages to a queue called CompositeQueue.q (it doesn't have to be called that way).
That queue is rooting messages to a topic called Topic.a and a queue called Queue.b.

All of the required configuration is done in the ActiveMQ XML configuration file. Below, there is snippet of the broker configuration file where the above example is configured.


<broker ...>
    <destinationInterceptors>
      <virtualDestinationInterceptor>
        <virtualDestinations>
          <compositeQueue name=“CompositeQueue.q">
            <forwardTo>
               <topic physicalName=“Topic.a" />
               <queue physicalName=“Queue.b" />
            </forwardTo>
          </compositeQueue>
        </virtualDestinations>
      </virtualDestinationInterceptor>
    </destinationInterceptors>
  </broker>

The interesting thing here is that you can mix queues and topics without making any changes in the client code and this is not part of the JMS specification.

You can also extend that to use composite topics pretty much on the same way… Below you'll find a similar broker configuration to use Virtual Topics:


<broker ...>
    <destinationInterceptors>
      <virtualDestinationInterceptor>
        <virtualDestinations>
          <compositeTopic name="VirtualTopic.A">
    <forwardTo>
           <queue physicalName="FOO" />
           <topic physicalName="BAR" />
    </forwardTo>
          </compositeTopic>
        </virtualDestinations>
      </virtualDestinationInterceptor>
    </destinationInterceptors>
  </broker>

So, with a simple change in the ActiveMQ broker configuration you can dramatically change the way
the system works and extend it to your needs without changing the client application.


Comments

  1. Hello.
    I believe there is a problem with the second configuration snipped you posted here.
    The tag is closed before (which is unrecognized as a result).
    And even when fixed, the xsd doesn't allow children for .
    Is there a way to get around this? I would like to change virtualTopic to compositeTopic inside activeMQ configuration without changing queue names in all the clients. And that means leaving "VirtualTopic." prefix, so using compositeTopic doesn't help - it's still recognized as virtualTopic.
    If this thing worked, it would fit my case perfectly (forwarding messages from virtual topic to preconfigured queues).
    Could you please clarify your example?

    ReplyDelete
    Replies
    1. The "virtualTopic" tag is closed before "forwardTo" (which is unrecognized as a result).
      And even when fixed, the xsd doesn't allow children for "virtualTopic".
      -- tag names got cut off

      Delete

Post a Comment

Popular posts from this blog

Calling Web Services with Apache Camel

How to Declare Variables in MS-SQL Server Management Studio

Using HTTP-based endpoints with Apache Camel