FioranoMQ architecture allows multiple FioranoMQ Servers to be connected together, allowing clients connected on one server to exchange information with clients connected to any other MQ Server. Using FioranoMQ Repeater, servers can be connected both over LAN (Local Area Networks) and WAN (Wide Area Networks).
FioranoMQ Server clustering allows clients connected to different FioranoMQ servers to exchange information by setting up an instance of the FioranoMQ Repeater. This feature is particularly useful in deploying applications that need to communicate with other applications across geographically distributed sites. For instance, take the example of an organization with offices in New York, San Francisco, and Boston. Here, a client of an MQ Server located in the Boston office can communicate with a client of an MQ Server located in the New York office. This is easily achievable with server-to-server communication, facilitated by a repeater. With Server-to-Server communication, each client application in Boston only needs to connect to the Boston FioranoMQ Server.
The FioranoMQ Administrator can configure the Repeater to automatically forward relevant messages from the Boston server to the FioranoMQ Server in New York and/or San Francisco, based on specified requirements. These messages are delivered to the subscriber applications that are connected to the New York and/or San Francisco servers. If there are transient network failures across the WAN connecting Boston, New York and San Francisco, none of the client applications are affected. Publishers can continue to publish messages locally. These messages are persistent on the local server of the publisher if a durable link (For more information, read the Subscription Mode and Choice of Selectors section) on the repeater connects the concerned FioranoMQ servers. The subscribers stay connected and receive messages, if any are available, from their local server. The repeater also takes care of reconnecting the servers in case of temporary network failures.
FioranoMQ Repeater enables the communication between different servers by using the Publish/Subscribe messaging model. This implies that information is exchanged between the topics on different servers and the repeater cannot be used for the exchange of information over queues. All Server-to-Server communication is handled in a transparent manner by FioranoMQ internally and the client application does not need to be modified in any way. MQ Servers can be part of the same LAN or can be spread across multiple WANs.
The FioranoMQ Repeater allows information exchange over SSL/HTTP/HTTPS in addition to the default TCP/IP communication.
Salient Features
FioranoMQ Repeater offers the following features:
- Easy Configuration: FioranoMQ Repeater can run as embedded in the same container in which the server is running, or can run as a standalone component (separate process) and can be used to wire multiple servers. FioranoMQ Repeater provides complete power to the enterprise administrator to configure MQ Servers on any network topology. An administrator can set up topics on the source as well as target servers that exchange information between them. Configuring the Repeater is simple and is XML based.
- Connection Topology: The Administrator of FioranoMQ can configure the Repeater to set up a connection between servers and propagate messages on the connection.
The repeater can be configured to support different kinds of network topologies:
- Hub-spoke: A source server can be linked with N number of target servers and vice-versa. In the former case, the single source server acts like a message broadcast hub for all target servers. All messages published on the source server can reach one or all of the target servers depending on the requirement. Similarly, in an opposite scenario, a single target server can act as a hub for many source servers and receive messages published on one or all source servers.
- Mesh: A cluster of FioranoMQ servers can be set up in a manner where each server is connected to all other servers in the cluster through the repeater, forming a mesh type of structure. Messages published one server can reach other servers in the cluster, depending upon the topics on which the messages are published.
- Bus based: The repeater can be used to set up a cluster of FioranoMQ Servers, in which a single source server represents a message bus. Target servers behave as recipients of messages from this bus where only one message can be received by only one target server at any point of time.
No Changes in the Client Application
Client applications can communicate with any number of FioranoMQ Servers connected through the Repeater. Clients connected to one server can exchange messages with clients connected to another server, without each client having to explicitly connect to the same server. The client application does not need to be modified in any manner - the FioranoMQ Repeater forwards messages pertaining to a particular topic across servers. The administrator only has to configure the repeater to forward messages pertaining to desired topics across servers.
Robustness in Handling Network Failures
Data transfers between multiple FioranoMQ Servers (connected to each other through the Repeater) can be made to use Persistent Messages/Durable Subscriptions as an option. In this case, messages transferred between se rvers are always logged onto persistent storage, thereby making the system highly reliable and robust in the event of network failure.
In the event of a network connection going down, the repeater tries to bring it up. The repeater tries to reconnect to the server with which it lost a connection repeatedly, with only a small interval between each try. This 'ping' time interval is configurable through Fiorano Studio. The pinging operation continues until a connection is re-established (where the "down" server finally comes up again).
Subscription Mode and Choice of Selectors
The FioranoMQ Administrator can configure the Repeater to create either Durable or Non-Durable links between the source and target servers. A durable link can be used to ensure that no messages are lost across the repeater in case of network failure.
Message selectors can be set on a link between servers to allow only the required messages to be exchanged between them. These can be useful, especially in setting up the bus-based network topology. For more information, read the Connection Topology section.
Request/Reply Across Repeater
The Repeater provides functionality for using request-reply service over FioranoMQ servers, which are linked by repeater. This allows a requestor, publishing request messages on topic t1 on server S1 to get replies for the requests. These replies are received from a replier on topic t2 on server s2. The repeater can be set up, with little effort, to perform a request-reply scenario.
Dynamic Replication Links
FioranoMQ can be used to create new replication links dynamically. This enables the applications to replicate messages on topics that are created after the repeater has started. Administrators do not have to manually add replication links for all topics. They need only specify a pattern - 'ABC*' - and the FioranoMQ repeater would create replication links for all topics that match the pattern. If a new matching topic is created after the repeater starts, a replication link for that topic is created dynamically.
Repeater with Load Balancing
The repeater can be put to best use in a Load Balanced cluster of FioranoMQ Servers. FioranoMQ uses the dispatcher for load balancing client connections among different FioranoMQ Servers.
Repeater Link
The repeater replicates messages in the link specified between a source and a target server. A repeater can have N number of links configured. By default, the server sets up only a single link to the repeater. Properties related to this default link can be edited prior to creating and managing additional links in the online mode. The Link element, within the Repeater Manager MBean provides, has the following information:
Status: Specifies the link is running or not.
- SourceServer: Specifies the server on which subscriptions are created. Source Server contains the ConnectionInfo.
- TargetServer: Specifies the server on which publishers are created. Target Server contains the ConnectionInfo.
Connection Information
The Connection Information enables the repeater to connect to source or target servers. Target Server as well as Source Server within a link is associated with an instance of Connection Information. An instance of ConnectionInfo contains the elements as listed in the table Configuration Parameters.
Link Topic Information
Each Link could be associated with one or more Topic Links. Each Topic Link refers to source/target topic information. A repeater picks up messages from the source topic and sends them to the target topic.
A link could also have an instance of a Request/Reply Topic. Information regarding the source and target topics are request-reply services only. They are used when LinkTopic uses a request-reply message transfer.
Configurable parameters of LinkTopicInfo are summarized below:
Configuration Parameters
Topic Link Information Parameters | Description | |
Source Topic Name | Specifies the name of the topic on which subscriptions are made on source server of the link containing LinkTopicInfo. The name supports the wild-card character '', which enables the repeater to create subscriptions on all the topics that matches the source topic. For example, if the source topic name is 'ABC', subscriptions will be made on topics such as ABC1, ABC12, ABCDEF, and so on. |
|
Target Topic Name | The name of the topic on which messages received for the above subscription are forwarded to the target server of the link containing LinkTopicInfo |
|
ReplyOn | Specifies the topic name on which the repeater listens for replies which it receives on requests it forwards on LinkTopicInfo. |
|
isDurable | Specifies whether the link between the source and the target is durable. A durable link ensures that no messages are lost across the repeater in the event of a network failure. The values for this variable are "yes' and "no". |
|
Message Selector | Specifies the selector that is set on a link between servers to allow only required messages to be exchanged between them. |
|
Type | Specifies whether the link should be constantly connected to the target server or replicated only if a subscriber exists. |
|
ReplyTopicInfo Parameters | Description | |
ReplyTopicName | Specifies the name of the ReplyTopic |
|
isDurable | Specifies whether the link between source and target is durable. A durable link can be used to ensure that no messages are lost across the repeater in the event of a network failure. The values for this variable are "yes' and "no". |
|
Message Selector | Specifies the selector that is set on a link between servers to allow only required messages to be exchanged between them. |
|
Wild Character Support
FioranoMQ provides support for wild-card characters in repeater configurations so that separate links need not be added to each topic. A user can specify wild-card characters in the source topic. All topics starting with the string mentioned in the source topic can be repeated.
A Repeater can be configured to replicate messages that match a particular pattern. This pattern can be specified in the source topic name of the Properties Name. For example, if the Source Topic Name is specified "ABC*", the topics that match this pattern (all the topics starting with the string "ABC" on the source server) are repeated across two servers. All subscribers subscribing to ABC, ABC1, ABCZ and so on will be able to receive messages published on source topics ABC, ABC1, and ABCZ respectively, via the FioranoMQ repeater.
Topics created dynamically that matches the pattern, 'ABC*' are replicated as well. Where 'ABC2' gets created after the repeater starts leads to creating, dynamically, a replication link for 'ABC2' (topic on source server) to 'ABC2' (topic on target server). And where a topic name (like 'ABD1') that does not match the pattern ('ABC*') gets created, the replication link is not added.
Dynamic Link Propagation
The Repeater can be configured to replicate messages only on demand, that is, messages would travel from source to target only if there is a consumer (active or passive) on the target server interested in the message. A pre-configured link in the repeater remains in a "stopped" mode if there are no consumers on the destination. This link is activated as soon as a consumer is created.
By default this feature is turned "off".
Note: For this function, events need to be turned on in the server connected to repeaters.
Request/Reply across Servers
The FioranoMQ Repeater provides a mechanism for using request-reply service across two servers. An intermediate topic on the target server is needed so as to receive replies from the replier and forward them to the requestor.
A Possible Scenario:
- A requestor (REQ) connected to FMQServer 1, is publishing request messages on topic t1. The requestor awaits a reply for requests on a temporary topic created for the connection.
- A replier (REP) connected to FMQServer2, is subscribing to request messages on topic t2. On receipt of messages, the replier sends a reply to the request message on the reply topic that is specified in the JMSReplyTo property of the request message.
- Using repeater, the requestor REQ on topic T1 of Server1 can get replies for requests made by it.
- Specify the replytopicname as T3 using Fiorano Studio.
- Create a topic T3 on the Server2 (target server)
Refresh the Repeater
The SourceTopicName and the TargetTopicName can have the same name. Similarly, the replyOn value signifies the topic that is used by the target server for publishing replies to messages. This is for messages forwarded on that topic link, represented by LinkTopicInfo. The ReplyTopicInfo represents information about the replier topic link used in request-reply services across servers.
In addition, a permanent topic t3 has to be established on the target server if the reply is to be sent to a temporary topic on the source server. This is because the repeater requires a topic on which it listens to replies for requests that it has forwarded.