Which TIBCO EMS architectures are used for migrating to Amazon MQ? - Amazon MQ
Option 1: TIBCO EMS cross-regional architecture in AmazonOption 2: TIBCO EMS high availability architecture
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Which TIBCO EMS architectures are used for migrating to Amazon MQ?

You can migrate from TIBCO EMS to Amazon MQ using cross-regional architecture in Amazon or TIBCO EMS high availability architecture.

Option 1: TIBCO EMS cross-regional architecture in Amazon

The below diagram shows the typical architecture of TIBCO EMS routing between two TIBCO EMS Servers in different regions, common in many enterprise systems. TIBCO EMS Server EMS_ORANGE is deployed in the us-east-1 region and EMS_APPLE is deployed in the us-east-2 region: Diagram showing message flow between EMS_ORANGE and EMS_APPLE systems with topics and queues. For application App 1 to communicate with App 2:

  1. App 1 uses a topic destination, Topic1 on server EMS_ORANGE to publish messages.

  2. Published messages are transmitted to topic Topic1 on server EMS_APPLE using the configured route.

  3. On EMS_APPLE, a bridge is configured to move messages from topic, Topic1 to queue, Queue1. Messages are then consumed by App 2.

Option 2: TIBCO EMS high availability architecture

In this configuration, High availability is provided by configuring a pair of servers, Primary and Secondary. In a typical enterprise architecture, two high availability configurations, shared and unshared. The shared state setup is the most widely used setup in enterprise settings. The following diagram demonstrates the Shared State configuration for a pair of messaging servers: Diagram showing clients connecting to primary and secondary servers, with a shared resource locked by the primary server.

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.

Note

The above configuration is unable to support more than two servers, and data replication across the servers for durability.