4 Replies Latest reply: Aug 11, 2011 5:11 PM by GabrielV RSS

    Designing a message queuing architecture

    879917
      Hi,

      I am an engineering student working on a project that needs a message queuing system to be implemented to ensure a communication between different entities of the whole system.

      - Suppose we have three entities: A,B and C.
      - Each entity is configured with an IP Address.
      - I need to send messages between them: A to B, B to A, A to C, C to A, A to B and B to C.

      What would be the best architecture that fits my needs:
      - Must i run a broker on each entity?
      - What about using 2 Queues to ensure communication in two ways ...

      Any idea will be appreciated :)

      Thanks in advance.
        • 1. Re: Designing a message queuing architecture
          Nigeldeakin-Oracle
          What would be the best architecture that fits my needs:
          That's too big and general a question to be able to answer in a forum post. But if you're using Java you can certainly achieve it using JMS. You'd use a separate queue for each stage of that sequence.

          Note that in JMS, the sender and the receive of a message don't connect directly to each other; instead they connect to the JMS provider. The name of the queue is an abstraction which removes the need for a sender and receiver to know anything about each other.
          Must i run a broker on each entity?
          No. You can use a single MQ broker for everything. You would typically use a cluster of MQ brokers if you wanted more resilience against broker failure.
          What about using 2 Queues to ensure communication in two ways ...
          Yes, you would.

          Nigel
          • 2. Re: Designing a message queuing architecture
            879917
            Hi nigeldeakin,

            Thank you for you reply,
            For sure i will use JMS, and i can imagine that i can use separate queue for each stage as you mentionned ...
            But my question is:
            - What would be the consequences of running a separate broker on each entity?
            - My point is to address the message to it's target (destination) using the target's IP Address, so if each entity has a broker running on it then i will be able to connect to that broker and send a message to his inbound queue (a listener will be running at the destination and will consume the incoming messages).

            Any other proposal will be greatly valued :)
            • 3. Re: Designing a message queuing architecture
              Nigeldeakin-Oracle
              imad wrote:
              - What would be the consequences of running a separate broker on each entity?
              If you've configured the brokers to work together in a cluster then messages will be delivers from a producer on one broker to a consumer on another. If you don't configure the brokers to work as a cluster (i.e. they are all independent) then they won't.
              - My point is to address the message to its target (destination) using the target's IP Address,
              It's best to think of the name of the destination, and the location of the broker, as being separate things.
              so if each entity has a broker running on it then i will be able to connect to that broker and send a message to his inbound queue
              (a listener will be running at the destination and will consume the incoming messages).
              You could do that, but it's really missing the point of JMS, which is to avoid the need for the sender of a message from having to know the location of the receiver of the message.

              Nigel
              • 4. Re: Designing a message queuing architecture
                GabrielV
                Hello imad,

                Sure a HA cluster is a good idea too, where clustered brokers have common queues. To move messages between queues, you can use the bridge service. The bridge service allows to clients send/receive messages from local queues, not taking care where the messages will be forwarded (or where did they come from). A good practice is to have a queue/topic for each purpose (e.q. A_to_B_send, A_to_B_reply, ..). So to have a two way communication, its better to use two separate queues.

                If you have an unreliable infrastructure and you still want the clients to connect, maybe you could have a look at the bridge service too. We have built a distributed messaging environment and to have RELIABLE connection, we did

                - run a message broker on each node (A, B, C)
                - you may have only one consumer for a queue, so if you want to distribute messages to more endoints, you will have to use a topic
                - set up bridges between queues (no circular ways)

                The bridge allows to sender to send messages, receivers to read messages even the network is down. When the network is connected, the messages are moved.

                Good luck
                Gabriel

                Edited by: user8961075 on 11.8.2011 15:07