Solace Message VPN bridge limitation

sysem
sysem Member Posts: 15 ✭
in General Discussions #1

Are there any limitation for sending / receiving message for solace message vpn bridging (bi-directional)??
e.g.
Is it possible to send message targeting to a queue on the bridged vpn ?? Or it is only possible to send message targeting to a topic ??

Answers

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 636 admin
    #2

    Ideally, most routing in Solace is done via Topics. Bridges can be configured to attract topics via subscriptions (either Direct, or Guaranteed via a VPN bridge queue), and then are republished on the other side. If you want a remote queue to receive the message, then subscribe your queue to the topic and it will receive it after it flows across the bridge. This pattern is typical in Solace architectures: for Persistent/Guaranteed flows: publish to a topic, and have your queue subscribe to that topic to receive.

  • sysem
    sysem Member Posts: 15 ✭
    #3

    as it is similar to request response message... i do not want to send to a topics.. that may be received by other queue...
    e.g.
    i would like to send a message target to a queue (where sender and receiver are on 2 different VPN), in case we setup the bridged VPN (bi-directional)...

    is it possible that sender on VPN A can send message target to a queue on VPN B ?? and receiver on VPN B can reply the message and send the response back to sender on VPN A ?

  • Abhikesh
    Abhikesh Member Posts: 34 ✭✭
    edited December 2019 #4

    @sysem it's possible via Solace Network Topic.
    Let’s say you have followings bi-directional bridge:
    1: VPN_A_TO_VPN_B
    Create Bridge Queue on VPN_A and Solace Bridge on VPN_B and map network topic of Bridge Queue on VPN_B.
    Whenever you publish messages on VPN_A Bridge Queue, it will forwarded to VPN_B and from there you can consume.
    2: VPN_B_TO_VPN_A
    Create Bridge Queue on VPN_B and Solace Bridge on VPN_A and map network topic of Bridge Queue on VPN_A.
    Now whenever you publish messages on VPN_B Bridge Queue, it will forward to VPN_A and from there you can consume.
    In above both case you are publishing on Queue and consuming from Queue.

    Please let me know if I understate your question in other way, happy to help.

  • SasikumarSP
    SasikumarSP Member Posts: 31 ✭✭
    #5

    @sysem
    Question>> as it is similar to request response message... i do not want to send to a topics.. that may be received by other queue...

    Suggestion>> As Aaron suggested it always best practice to use topic on the publisher side until otherwise, you have some restriction on the tool which don't support topic publisher. You can use different topic pattern not used by other queues.

    Question>> is it possible that sender on VPN A can send message target to a queue on VPN B ?? and receiver on VPN B can reply the message and send the response back to sender on VPN A ?

    Suggestion>> yes, add the network topic of a target queue in VPN B to topic subscription of a bridge queue in VPN A. If you publish the message on queue name in VPN B, it will receive the message.
    vice versa for response, add the network topic of target queue in VPN A to topic subscription of a bridge queue in VPN B.
    Its not required to have the physical queue present on publisher side. JNDI queue name needs to be added in case if you are doing queue lookup from JMS API.

  • Rishal
    Rishal Unconfirmed, Member Posts: 2 ✭
    #6

    @Abhikesh as mentioned in point 1 how can I map network topic of bridge queue on VPN_B

  • SasikumarSP
    SasikumarSP Member Posts: 31 ✭✭
    #7

    @Rishal
    The best practice to configure a bridge queue on publisher msg-VPN and add a queue's network topic on the bridge queue as a topic subscription. For example, you want to publish a message on queue endpoint: Q_solace_Test then, add #P2P/QUE/Q_solace_Test (network topic format of a queue) as a topic subscription on the bridge queue. Add the same network topic format on the destination msg-VPN queue's topic subscription where the consumer connects. Please note, the queue Q_solace_Test not required to be physically created on publisher msg-VPN.

    Sender --> msg-VPN A --> Bridge Queue (with #P2P/QUE/Q_solace_Test) --> VPN Bridge --> msg-VPN B --> Consumer Queue (with #P2P/QUE/Q_solace_Test).

    *Bridge queue - is a normal queue endpoint to where the VPN bridge connects. It should be exclusive.
    *Consumer queue - is a normal queue endpoint where consumers bind and receive messages.

  • SasikumarSP
    SasikumarSP Member Posts: 31 ✭✭
    #8

    @Rishal,
    Solace supports Dynamic Message Routing (DMR) now. Please check the DMR concept in the solace document and decide to go either with VPN bridge or DMR.

Categories

This Month's Leaders

This Week's Leaders