In the above diagram, a pair of messaging servers share a state by sharing file-based storage. The primary server attains the lock on the shared storage capacity, becomes active, and accepts client connections, while the secondary server remains in passive mode. Meanwhile, the primary and secondary servers will be made aware of one another's status via periodic, heartbeat pings.
In te case of a failover, the secondary server will assume the state of the primary server, and acquire the lock on the shared state.
NoteThe above configuration is unable to support more than two servers, and data replication across the servers for durability.
Replicating TIBCO EMS with Amazon MQ
Amazon MQ provides a variety of broker configurations, various instance sizes for different workloads, and broker options such as single instance, single instance mesh, active/standby instance or active/
standby mesh for high availabilty and message durability. To learn more about supported broker options, see Amazon MQ Broker Architecture.
In this section, we replicate the architecture of the TIBCO EMS system shown in the previous section with Amazon MQ while keeping the same configuration.
Note
If you wish to use a single region, you can simply deploy your Amazon MQ brokers in one region with the active/standby configuration. You can also optimize the performance of your Amazon MQ brokers by taking advantage of the Apache ActiveMQ optimization settings.
The following diagram illustrates Amazon MQ configured across two regions with a linear connection between two active/standby brokers:
Steps to re-platform
Note
• A Global Topic with the same name has to be created on other EMS Servers for forwarding messages to the Topic on those EMS Servers. In Amazon MQ, a global topic is not required.
Once 2 brokers are connected using a network connector, they begin to share all queues/
topics, and their data.
• In Amazon MQ, a routed queue as implemented by a TIBCO EMS server is not required.
• A network bridge from a topic to a queue can be used in TIBCO EMS architecture to avoid the naming issue with routed queues and to provide multi-hop capability between EMS servers using a Topic. In Amazon MQ, queue names are consistent and all topic/queue messages are shared among a Networks of Brokers.
• Currently, Amazon MQ only supports JMS 1.1. Applications written for JMS 2.0 can be migrated to Amazon MQ using the Qpid JMS library, which uses AMQP instead of the default, higher-performing Openwire protocol. For more details, refer to the Amazon MQ workshop.
Steps to re-platform
You can use the following procedure to migrate the TIBCO EMS architecture shown here (p. 25) to an equivalent Amazon MQ architecture without impacting App 1 or App 2:
1. Create an active/standby broker in us-east-1 and another in us-east-2 named as AMQ_ORANGE and AMQ_APPLE.
2. Create a Network Bridge between 2 brokers by adding a duplex network connector definition to one of the queues:
<networkConnectors>
<networkConnector duplex="true" name="connector_AMQ_ORANGE_to_AMQ_APPLE"
uri="masterslave:(ssl://b-d63bcc4d-682b-40a2-8227-31386bcf1e3d-1.mq.us- east-2.amazonaws.com:61617,ssl://b-d63bcc4d-682b-40a2-8227-31386bcf1e3d-2.mq.us-east-2.amazonaws.com:61617)" userName="amqadmin"/>
</networkConnectors>
After the reboot of AMQ_ORANGE, there should be a Network Bridge created between both brokers as illustrated below:
Note
Steps 1 and 2 can be replicated using a AWS CloudFormation template. For more information about using AWS CloudFormation to set up Amazon MQ brokers, see the Amazon MQ AWS CloudFormation Template Reference.
3. Retrieve the list of static TIBCO EMS server destinations from the config files, queues.conf and topics.conf or by using the following tibemsadmin commands:
show queues * static show topics * static
Testing and validation
When finished, update the Amazon MQ broker AMQ_ORANGE configuration file to add startup destinations as shown here:
<destinations>
<queue physicalName="FOO.BAR"/>
<topic physicalName="SOME.TOPIC"/>
</destinations>
4. Destination properties for TIBCO EMS can be found in queues.conf and topics.conf files. Per Destination level Policy can be set in Amazon MQ using the destinationPolicy section in the configuration file.
5. Retrieve the list of TIBCO EMS Bridges from bridges.conf. For example, the Bridge from source topic NOTIFY.FOOBAR to target queues FOO and BAR is shown as:
[topic:NOTIFY.FOOBAR]
queue=FOO queue=BAR
When finished, up the Amazon MQ broker AMQ_ORANGE configuration file to add Composite Destinations that match TIBCO EMS bridges.
NoteSimple Topic to Queue bridges are needed in TIBCO EMS to support m-hop routing. In Amazon MQ this is not needed and queues can be used directly with a Network of Brokers.
Testing and validation
In the the section called “TIBCO EMS typical architecture” (p. 25) section, a Topic to Queue bridge was used to forward messages to other EMS servers. In Amazon MQ, App 1 would send messages directly to Q1 because messages on a queue are forwarded in a Network of Brokers.
In the TIBCO EMS example, messages from App 2 are sent to Q2 and then forwarded to Q2@EMS_APPLE.
In Amazon MQ, the queue name, Q2, would be the same on both message brokers, simplifying the configuration of App 1.
The following example shows the AMQ_ORANGE broker with consumers in us-east-1 and AMQ_APPLE with consumers in us-east-2
Testing and validation