Browse Prior Art Database

Exposing a single destination name in a multi-tenant MQ environment Disclosure Number: IPCOM000216712D
Publication Date: 2012-Apr-16
Document File: 1 page(s) / 43K

Publishing Venue

The Prior Art Database


Avoiding name clashes in a multi-tenant Message Queueing environment

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 01 of 1

Exposing a single destination name in a multi -tenant MQ environment

When some Message Queueing products move into the cloud environment multi-tenancy problems can be encountered. The problem is stated thus... Assuming that there are two users.

Each user is unaware of the other.

    Each user is creating and deleting queues or topics on the same Queue Manager (QM) (it's "the cloud" so they don't know that they are working on the same QM).

Each user wants to create their first queue (MY_QUEUE)

At this point, we have a problem.....There is no namespace so the Message
Queueing product is not able to distinguish MY_QUEUE (User A) from MY_QUEUE (User B).

    The normal way for this to work, in some Message Queueing products, is that the queue creator understands that they cannot have multiple instances of the same queue and that they need to rename the queue, if they want to re-use it. However, in a cloud environment where QMs will be shared across multiple users who are not aware of each other this is not an acceptable level of behaviour.

    This disclosure discusses a method for allowing the user to deploy a queue (or topic) with the same name as another user's destination to a single QM and be agnostic of the other user's queue.

This is done by a DNS style trick whereby the queue is no longer referenced as MY_QUEUE@QM but rather MY_QUEUE@MYACCOUNT. By giving the Message Queueing product the namespace of MYACCOUNT, we can connect the clients to the correct instance of MYQUEUE....