EMS

EMS 5.1TIBCOs Enterprise Messaging OfferingMessage MODELSJMS Message ModelsPoint-to-Point (Queues)

Publish Subscribe (Topics)

Multicast (Topics)

Point-to-Point(Queues)Message ProducerQueue

TIBCO EMS ServerSend MessageReceive MessageAcknowledgeMessage ConsumersPublish-Subscribe(Topics)Message ProducerMessage ConsumersTopic

TIBCO EMS ServerPublish MessageDeliver MessageAcknowledgeSubscribe to TopicMulticast(Topics)Message ProducerMulticast Topic

TIBCO EMS ServerPublish MessageBroadcast MessageMessage ConsumertibemsmcdDeliver MessageSubscribe to MessageMulticast DaemonEMS : An extension to JMSEMS Extensions to JMS Messages - IJMS provides 2 delivery modes for messages

PERSISTENT

NON_PERSISTENT

EMS adds the 3rd delivery mode

RELIABLE_DELIVERYEMS Extensions to JMS Messages - IIFor restriction of acknowledge messages in JMS

NO_ACKNOWLEDGE mode

To restrict acknowledgement in EMS, there are also

EXPLICIT_CLIENT_ACKNOWLEDGE modeEXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE modeEMS Extensions to JMS Messages - IIIEMS extends MapMessage and StreamMessage body types of JMS which allow EMS to exchange messages with TIBCO RV and ActiveEnterprise formats.

The extensions are : Can nest a MapMessage or StreamMessageCan use arrays as well as primitive types for values

Message STRUCTUREMessage StructureHEADERPROPERTIESBODYREQUIREDMessage HeadersJMSDestinationDestination to which message is sent.

JMSDeliveryModePersistent, Non-persistent or Reliable. Default is Persistent.

JMSExpirationLength of time the message will live before expiry.

If the server expiration property is set for a destination, it will override the JMSExpiration value set by the message producer.Message HeadersJMSPriorityPriority of the message. Larger numbers indicate higher priority.

JMSMessageIDUnique identifier for a message.

JMSTimeStampTimestamp of the time when the message was handed off to a provider to send. Message may actually be sent later than this timestamp.Message HeadersJMSCorrelationIDThis ID can be used to link messages, such as linking a response message to a request message.

JMSReplyToA destination to which a message reply should be sent.

JMSRedeliveredIf this field is set, it is possible that the message has been delivered to the client earlier, but not acknowledged at that time.Message PropertiesJMS_TIBCO_CM_PUBLISHERJMS_TIBCO_CM_SEQUENCEJMS_TIBCO_COMPRESSJMS_TIBCO_DISABLE_SENDERJMS_TIBCO_IMPORTEDJMS_TIBCO_MSG_TRACEJMS_TIBCO_MSG_EXTJMS_TIBCO_SENDERJMS_TIBCO_SS_SENDERJMS_TIBCO_PRESERVE_UNDELIVERED

Undelivered Message Queue

Message ExpiryQueuemaxRedelivery12ORJMS_TIBCO_PRESERVE_UNDELIVERED = TRUEBODYPROPERTIESHEADERSERVERUndelivered message queue$sys.undelivered

JMS_TIBCO_PRESERVE_UNDELIVERED = FALSEBODYPROPERTIESHEADERSERVER

Message BodyMESSAGE TYPECONTENTS OF BODY MESSAGEMessageNo BodyText MessageJava.lang.StringMap MessageName/Value pairsBytes MessageStream of bytesStream MessageStream of primitive data typesObject MessageSerializable objectEMS supports messages up to a maximum size of 512MBMessage DELIVERY MODESPersistentWhen a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation.

The message is persisted on disk by the server. This delivery mode ensures delivery of messages to the destination on the server in almost all circumstances.

However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages.PersistentMessage ProducerEMS ServerMessageAcknowledgementNon PersistentSending a NON_PERSISTENT message omits the overhead of persisting the message on disk to improve performance.

If authorization is disabled on the server, the server does not send a confirmation to the message producer.

If authorization is enabled on the server, the default condition is for the producer to wait for the server to reply with a confirmation in the same manner as when using PERSISTENT mode.Non PersistentMessage ProducerEMS ServerMessageDepending onnpsend_check_mode

Regardless of whether authorization is enabled or disabled, you can use the npsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to the producer.Reliable DeliveryEMS extends the JMS delivery modes to include reliable delivery. Sending a RELIABLE_DELIVERY message omits the server confirmation to improve performance regardless of the authorization setting.Message ProducerEMS ServerMessageReliable DeliveryWhen using RELIABLE_DELIVERY mode, the server never sends the producer a receipt confirmation or access denial and the producer does not wait for it.

Reliable mode decreases the volume of message traffic, allowing higher message rates, which is useful for messages containing time-dependent data, such as stock price quotations.

When you use the reliable delivery mode, the client application does not receive any response from the server. Therefore, all publish calls will always succeed (not throw an exception) unless the connection to the server has been terminated.Reliable DeliveryIn some cases a message published in reliable mode may be disqualified and not handled by the server because the destination is not valid or access has been denied.

In this case, the message is not sent to any message consumer. However, unless the connection to the server has been terminated, the publishing application will not receive any exceptions, despite the fact that no consumer received the message.EMS Delivery Modes ReviewedNON_PERSISTENT and RELIABLE_DELIVERY messages are never written to persistent storage.

PERSISTENT messages are written to persistent storage when they are received by the EMS server.PERSISTENT Mode RevisitedEMS Persistent Mode ManagementPersistent Messages Sent to QueuesPersistent messages sent to a queue are always written to disk. Should the server fail before sending persistent messages to consumers, the server can be restarted and the persistent messages will be sent to the consumers when they reconnect to the server.Message ProducerQueue

TIBCO EMS ServerSend MessageReceive MessageAcknowledgeMessage ConsumersDiskEMS Persistent Mode ManagementPersistent Messages Sent to TopicsPersistent messages published to a topic are written to disk ONLY IF that topic has at least one durable subscriber or one subscriber with a fault-tolerant connection to the EMS server.

Non-durable subscribers that re-connect after a server failure are considered newly created subscribers and are not entitled to receive any messages created prior to the time they are created.EMS Persistent Mode ManagementMessage ProducerOther ConsumersTopic

TIBCO EMS ServerPublish MessageSubscribe to TopicDurable ConsumersFault Tolerant ConsumersSubscribe to TopicStoreSubscribe to TopicWhen using file storage, persistent messages received by the EMS server are by default written asynchronously to disk.

When a producer sends a persistent message, the server does not wait for the write-to-disk operation to complete before returning control to the producer.

This means that the producer has no way of detecting the failure of persisting the message and take corrective action if the server fails before completing the write-to-disk operation.Persistent Messages & Synchronous Storage32Persistent Messages & Synchronous StorageWhat do you do if you want to SYNCHRONOUSLY write to disk?

You can set the mode parameter to sync for a given file storage in the stores.conf file to specify that persistent messages for the topic or queue be synchronously written to disk.

When mode = sync, the persistent producer remains blocked until the server has completed the write-to-disk operation.STOREStoreEMS ServerFile-based Store(Default)Database StoreWRITES TOStores.confPre allocate disk space for store fileTruncate the file to relinquish disk spaceMode : Sync or AsyncStore messages in DB or notProperties that allow the user to control how server manages the store fileDefine STORESDefault Store FilesFile based stores are enabled by default.

Server automatically defines 3 default stores$sys.nonfailsafeServer writes messages using asynchronous I/O calls.

$sys.failsafeServer writes messages using synchronous I/O calls.

$sys.metaServer writes state information about durable subscribers & fault tolerant connections.Message COMPRESSIONMessage CompressionTIBCO Enterprise Message Service allows a client to compress the body of a message before sending the message to the server.

EMS supports message compression/decompression across client types (Java, C and C#). For example, a Java producer may compress a message and a C consumer may decompress the message.

Message compression is supported in .NET clients when using the install package for Visual C++ 8 / .NET 2.0 or above.Message CompressionLess memory storage for PERSISTENT queue messages or DURABLE topic subscribers.

Compression option only compresses the BODY content. Headers and properties are NEVER compressed.

When messages are not stored, compression is not a good option. Why?Because, Compression takes TIME!Message CompressionCompression specific for individual messages.

Not on a per-queue or per-topic basis.

To set message compression

JMS_TIBCO_COMPRESS to TRUEMessage ACKNOWLEDGEMENTMessage AcknowledgementMessage ProducerTIBCO EMS ServerMessageMessage ConsumerMessageConfirmationAcknowledgementConfirmation of AcknowledgementJMSEMS (JMS + Below mentioned modes)CLIENT_ACKNOWLEDGENO_ACKNOWLEDGEAUTO_ACKNOWLEDGEEXPLICIT_CLIENT_ACKNOWLEDGEDUPS_OK_ACKNOWLEDGEEXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGEJMS : CLIENT_ACKNOWLEDGEConsumer is to acknowledge all messages that have been delivered so far by the session.

Possible for the consumer to fall behind in its message processing and build up a large number of unacknowledged messagesMessage ProducerTIBCO EMS ServerMessage 1Message ConsumerMessage 1Acknowledgement # 1,2,3Message 2Message 3Message 3Message 2CONSUMER ACKNOWLEDGESJMS : AUTO_ACKNOWLEDGE Session is to automatically acknowledge consumer receipt of messages when message processing has finishedMessage ProducerTIBCO EMS ServerMessage 1Message ConsumerMessage 1Acknowledgement 1Message 2Message 3Acknowledgement 3Acknowledgement 2Message 3Message 2SESSIONACKNOWLEDGESJMS : DUPS_OK_ACKNOWLEDGE Session is to "lazily" acknowledge the delivery of messages to the consumer.

"Lazy" means that the consumer can delay acknowledgement of messages to the server until a convenient time; meanwhile the server might redeliver messages.Message ProducerTIBCO EMS ServerMessage 1Message ConsumerMessage 1Acknowledgement #1,2Message 2Message 3Acknowledgement #3Message 3Message 2LAZYACKNOWLEDGEMENTEMS : NO_ACKNOWLEDGENO_ACKNOWLEDGE mode suppresses the acknowledgement of received messages.

After the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server.

Therefore, there is no need for the client application to send an acknowledgement to the server about the received message.Sessions created in no-acknowledge receipt mode cannot be used to create durable subscribers.EMS : EXPLICIT_CLIENT_ACKNOWLEDGEEXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE except it acknowledges only the individual message, rather than all messages received so far on the session.Message ProducerTIBCO EMS ServerMessage 1Message ConsumerMessage 1Acknowledgement 1Message 2Message 3Acknowledgement 3Acknowledgement 2Message 3Message 2CONSUMER ACKNOWLEDGESINDIVIDUALLYEMS : EXPLICIT_CLIENT_ACKNOWLEDGEWhen EXPLICIT_CLIENT_ACKNOWLEDGE would be used ?

When we receive the messages and put their information in a database and if the database insert operation is slow, you may want to use multiple application threads all doing simultaneous inserts.

As each thread finishes its insert, it can use this mode to acknowledge only the message that it is currently working on.EMS : EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGEEXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE is like DUPS_OK_ACKNOWLEDGE except it lazily acknowledges only the individual message, rather than all messages received so far on the session.Message SELECTORSMessage SelectorsA message selector is a string that lets a client program specify a set of messages, based on the values of message headers and properties.

A selector matches a message if, after substituting header and property values from the message into the selector string, the string evaluates to true.

Consumers can request that the server deliver only those messages that match a selector.DestinationsTypes of DestinationsStatic Destinations

Dynamic Destinations

Temporary DestinationsStatic DestinationsPurposeAllows administrators to configure EMS behavior at enterprise level

Scope of deliverySupports concurrent use

CreationUsing config files, tibemsadmin or by APIs by administrator

DurationUntil explicitly deleted by the administrator

Dynamic DestinationsPurposeProvide flexibility to define them as needed for short term use

Scope of deliverySupports concurrent use

CreationClient programs create it if permitted by server configuration

DurationAs long as at least 1 client actively uses it

QueueTopicSERVEROFFLINE DURABLE SUBSCRIBER

DYNAMIC DESTINATIONTemporary DestinationsPurposeIdeal for limited scope usage, like reply subjects (in routing)

Scope of deliverySupports local use

CreationClient programs create it

DurationExplicit deletion by the client or disconnection from the server

Mixed Bag - DestinationsClients can obtain references to static destinations through a naming service such as JNDI or LDAP

But they cannot obtain the references to dynamic or temporary destinations

Dynamic topics and queues have an asterisk (*) marked in front of them, when you use the commands show queues or show topics in tibemsadmin

If a property of a queue or topic has an asterisk (*) character in front of its name, it means that the property was inherited from the parent queue or topictibemsd TIBCO EMS ServerStarting the EMS Server

Running this service starts the EMS ServerThis service starts tibemsd.exe located in /bin foldertibemsd.exe reads tibemsd.conf for server settingsWHAT IF tibemsd.conf IS LOCATED IN SOME OTHER FOLDER?Using tibemsd to start EMS server

CAUTION

Need to create stores(.db files) manually in tibemsd.conf.

2. Need to specify the directory for other config files(default : bin folder) in tibemsd.conf

tibemsadmin TIBCO EMS AdminStarting tibemsadmin

Using connect

Using help

Using disconnect

Using exit

Using shutdown

Using show

Using create

Using delete

Using addprop

Using removeprop

Using setprop

Using purge

Using whoami & info

show serverUsing set

Parameters in tibemsd.confUsing time & timeout

The timeout value is the number of seconds the Administration Tool will wait for a response from the server after sending a command.77Using commit & autocommit

Using compact

The file will not be compacted unless the store_truncate parameter is enabled in the tibemsd.conf file (This is given in the EMS documentation, but it works fine for me even when I dont have a store_truncate parameter set)

If truncation is not enabled for the store file, the compact command will not reduce the file size. Truncation is enabled using the file_truncate parameter in the stores.conf file. (This is given in the EMS documentation, but it works fine for me even when I dont have a file_truncate parameter set)

79Using add

Using remove

Using grant & revoke

Using echo

Destination PROPERTIESchannelchannelChannel property determines the multicast channel over which messages sent to the topic are broadcast

Configure multicast channels in channels.conf file and enable this feature in tibemsd.conf

Cannot create channel by any command in tibemsadmin

Only 1 channel allowed for each topic

Available only for topics

channel

channels.conftibemsd.confchannel

exclusiveexclusiveAvailable only for queues

Set the exclusive property using addprop or setprop

When exclusive is set for the queue, the server sends all the messages on that queue to one consumer. No other consumer can receive messages from the queue.

Instead, these additional consumers act in a standby role; if the primary consumer fails, the server selects one of the standby consumers as the new primary and begins delivering messages to it.exclusive

expirationexpirationIf an expiration property is set for a destination, the server honors the overridden expiration period

If expiration property for the server is set, the server overrides the JMSExpiration value set by the producer in the message header

expiration=time[msec|sec|min|hour|day]expiration

maxbytesmaxbytesTopics & queues can specify the maxbytes property in the form maxbytes=value[KB|MB|GB]

FOR QUEUESmaxbytes: maximum size (in bytes) that the queue can store, summed over all the messages in the queue

If this limit is exceeded, the messages will be rejected by the server and the producer send calls will return an error

maxbytesFOR TOPICSmaxbytes: maximum size(in bytes) that the topic can store for delivery to each durable or non-durable online subscriber on that topic

The limit applies separately to each subscriber on the topic

Example : offline durable subscriber messages accumulate until they exceed maxbytes

non durable subscriber maxbytes limits the number of pending messages that can accumulate while the subscriber is online

maxbytes

maxmsgsmaxmsgsTopics & queues can specify the maxmsgs property in the form maxmsgs=value

maxmsgs: maximum number of messages that can be waiting in a queue

When adding a message into a queue/topic would exceed this limit, the server would reject the message and the producers send call returns an error

Can set both maxmsgs and maxbytes properties on the same queue. Exceeding either limit causes server to reject new messages until consumers reduce the queue size to below these limits.

maxmsgs

maxRedeliverymaxRedeliveryThe number of attempts the server should make to deliver a message sent to a destination maxRedelivery=count count is between 2 & 255

For messages that have been redelivered, JMSRedelivered header property is set to true JMSXDeliveryCount property is set to the number of times the message has been delivered to the destinationmaxRedelivery

overflowPolicyoverflowPolicyTo change the effect of exceeding the message capacity established by maxbytes or maxmsgs

overflowpolicy=default|discardOld|rejectIncoming

default

For TOPICSmaxbytes or maxmsgs exceed for a subscriber, that subscriber does not receive messageNo error returned to producer

For QUEUESNew messages are rejected by the server if maxbytes or maxmsgs are exceededError returned to producer

overflowPolicydiscardOld

For TOPICSOldest messages are discarded before they are delivered to the subscriber

Impacts subscribers individually. 3 subscribers, 1 exceeds the message limit. So, only the oldest messages for the one subscriber are discarded, while other two continue to receive all messages

No error returned to producer, as message can be delivered to some and discarded for others

For QUEUESError returned to producer if maxbytes or maxmsgs are exceeded

Oldest messages are discarded from the queue by the serveroverflowPolicyrejectIncoming

For TOPICSIf ANY of the subscribers have an outstanding number of undelivered messages on the server that are over the message limit, all new messages are rejected

Error is returned to producer

For QUEUESError returned to producer if maxbytes or maxmsgs are exceeded

Newest messages are rejected from the queue by the server

overflowPolicy

Quick QuizHow do I discard messages on myQueue when the number of queued messages exceeds 2500 ?

setprop queue myQueue maxmsgs=2500, overflowpolicy=discardOld

How do I reject all new messages published to myTopic when the memory used by undelivered messages for any of the topic subscribers exceeds 3 MB?

setprop topic myTopic maxbytes=3MB,overflowPolicy=rejectIncomingflowControlflowControlSpecifies the target maximum size the server can use to store pending messages for the destination

If number of messages > flowControlthen slow down the producers to the rate required by the message consumers

Useful when message producers send messages more quickly than message consumers can consume themUnlike overflowPolicy,flowControl never discards messages or generates error back to producer

flowControl

tibemsd.confprefetchprefetchConsumer and the EMS Server cooperate to regulate message fetching through this property

prefetch=value

ValueDescription2 or moreNever fetches more than specified number (Auto Fetch) 1Fetch only if it has no message (Auto Fetch) noneDisable Auto Fetch. Cannot be used with topics or global queues0 (default)Destination inherits the prefetch value. Default value for queues = 5 & topics = 64prefetchSERVERCONSUMER

2

1

5

4

3prefetch = 5ERROR$sys.undeliveredmaxRedelivery = 45431JMSXDeliveryCount = 20JMS_TIBCO_PRESERVE_UNDELIVERED = trueNow, messages belong to consumerJMSRedelivered = truefalseprefetch2 phases : messages from server to consumer

Fetch Phase

Consumer initiates fetch phase by sending a signal to the server that it is ready for more messages

Server responds by transferring one or more messages and gets stored in consumer

Accept Phase

Client code takes a message from the consumer

RECEIVE CALLprefetchAutomatic Fetch Enabled (prefetch = positive integer)

Improves performance by decreasing or eliminating client idle time while the server transfers a message

When a queue consumer prefetches a group of messages, the server does not deliver them to other queue consumers (unless the first queue consumers connection to the server is broken)

prefetchAutomatic Fetch Disabled (prefetch = none)Even when prefetch = none, a queue consumer can hold a message

ExampleA receive call initiates a fetch, but its timeout elapses before the server finishes transferring the messageThis leaves a fetched message waiting in the message consumerA second receive call does not fetch another message; instead it accepts the message already waitingThe third receive call initiates another fetchprefetchA waiting message still belongs to the queue consumer, and the server does not deliver it to another queue(unless the first queue consumers connection to the server is broken)

To prevent messages from waiting in this state for long periodsCall receive with no timeoutCall receive with timeout repeatedly and shorten the intervalPARENTCHILDall parents : nonenoneany parent : non-zero numeric valuehighestdoes not set any valuedefault(5 : queues, 64 : topics)INHERITANCEprefetch

securesecureIf secure is enabled for a destination, it instructs the server to check the user permissions whenever a user attempts to perform an operation on that destination

tibemsd.confsender_namesender_nameServer may include the senders username for messages sent to this destination

When connection between producer and server is established, server takes the username supplied by the producer and places it in the JMS_TIBCO_SENDER property of the message

But if producer sets the JMS_TIBCO_DISABLE_SENDER to true for a message, server will not add the sender name to the message

sender_namesender_name_enforcedsender_name_enforcedSpecifies that the messages sent to this destination MUST include the senders username

Unlike sender_name property, there is no way for message producers to override this property

This property overrides sender_name if already set.

sender_name_enforcedstorestoreSpecifies where the messages sent to this destination are stored

Configure stores in stores.conf

Stores.conf> store = myStore

testTopic store = topicStoreDestination BRIDGESBridgesSome applications require the same message to be sent to more than one destination, possibly of different types.

ExampleAn application can publish messages to several topics. All messages however, must also be sent to a database for backup and for data mining. A queue is used to collect all messages and send them to the database.

BridgesBridges are created between one destination and one or more other destinations of the same or of different types.

That is, you can create a bridge from a topic to a queue or from a queue to a topic. You can also create a bridge between one destination and multiple destinations.

For example, you can create a bridge from topic a.b to queue q.b and topic a.c.

Bridging Topic to QueuePublisherSubscriberSubscriberConsumerTopicA.BQueuequeue.BTIBCO EMS SERVERBridging Topic to Multiple DestinationsPublisherSubscriberSubscriberConsumerTopicA.BQueuequeue.BTopicC.BTIBCO EMS SERVERSubscriberBridging Queue to Multiple DestinationsSenderSubscriberConsumerQueuequeue.fooQueuequeue.BTopicC.BTIBCO EMS SERVERSubscriberConsumerBridgesWhen a bridge exists between two queues, the message is delivered to both queues. The queues operate independently; if the message is retrieved from one queue, that has no effect on the status of the message in the second queue.

Bridges are not transitive Topic A.B has a bridge to queue Q.B. Queue Q.B has a bridge to topic B.C. Messages delivered to A.B are also delivered to Q.B, but not to B.C.Creating a bridgeConfigured in bridges.conf file

Use of Selector All messages sent to a destination with a bridge are sent to all bridged destinations. This can cause unnecessary network traffic if each bridged destination is only interested in a subset of the messages sent to the original destination.

Bridges.conf[topic:A.B]queue=queue.Btopic=C.B selector="urgency in(medium, high)"ROUTINGRoutingEMS servers can route messages to other servers

Topic messages can travel one hop or multiple hops from the first server

Queue messages can travel ONLY ONE hop to and from the home queueRouting : Basic OperationEach route connects two TIBCO EMS servers.

Each route forwards messages between corresponding destinations (that is, global topics with the same name, or explicitly routed queues) on its two servers.

Routes are bidirectional; that is, each server in the pair forwards messages along the route to the other server.Routing : Hawk Eye ViewServer : AServer : BROUTEQueue : Q1Topic : T1Topic : T2Queue : Q1@ATopic : T1

GLOBAL TOPICGLOBAL TOPICGlobal Destinations : TopicsServer : AServer : BTopic : T1Topic : T2Topic : T1GLOBAL TOPICGLOBAL TOPICTopic : T2GLOBAL TOPICRoutes forward messages only between global destinations

For TOPICS, the global property must be set on both serversUnique Routing PathIt is illegal to define a set of routes that permit a message to reach a server by more than one path. TIBCO EMS servers detect illegal duplicate routes and report them as configuration errors.ABCEDPQRTSLEGAL(in all zones)ILLEGAL(in a multihop zone)ZonesA zone is a named set of routes.

Every route belongs to a zone.

Zones restrict the behavior of routes, so you can configure complex routing paths. Zones affect topic messages, but NOT queue messages.

Zones : Basic OperationIn a multi-hop (mhop) zone, topic messages travel along all applicable routes to all servers connected by routes within the zone.In a one-hop (1hop) zone, topic messages travel only one hop (from the first server).Queue messages travel only one hop, even within multi-hop zones.ABCEDZone : Z1mhopIf a message is sent to the global topic on server B, the server forwards the message to A,C,D,E provided there are subscribers on those serversIf Z1 were a one-hop zone, B would forward the message to A, C & D, but not to EEliminating Redundant Paths with One-Hop ZoneB1B2RMZone : Z21hopB1 & B2 : Producers @ Branch OfficeM : Consumers @ Main OfficeR : Consumers @ Back OfficeM serves consumers that process the message from branches B1 & B2

R serves consumers that record messages for archiving, auditing & backupGOAL : Forward messages from B1 and B2 to both M and ROverlapping ZonesM3M2M1M4B2B3B4B1D1D2D3D4Zone : Mumbai1hopZone : Bangalore1hopZone : Delhi1hopZone : IndiamhopCreating RoutesSyntaxcreate route EMS-SERVER url=tcp://ipserver:7222 zone_name=zoneName zone_type=1hop|mhop

route name MUST be the name of the EMS server which is specified in tibemsd.confurl indicates the other server by the URLActive & Passive RoutesA route connects two servers.

You may configure a route at either or both of the servers.

A route is active from the perspective of the server where it is configured. This server actively initiates the connection to the other server, so we refer to it as the active server, or initiating server.

A route is passive from the perspective of the other server. This server passively accepts connection requests from the active server, so we refer to it as the passive server.Active Active RoutesTwo servers can both configure an active route one to the other. This arrangement is called an active-active configuration.

For example, server A specifies a route to server B, and B specifies a route to A. Either server can attempt to initiate the connection. This configuration results in only one connection; it does not result in redundant routes.

You can promote an active-passive route to an active-active route by using this command on the passive server create route name url=urlThe url argument is required, so that the server (where the route is being promoted) can connect to the other server if the route becomes disconnectedRouted Topic MessagesA server forwards the message along the routes only when the global property is defined by the topic

Routed Topic MessagesTopic messages can traverse multiple hops.

When a route becomes disconnected (for example, because of network problems), the forwarding server stores topic messages. When the route reconnects, the server forwards the stored messages.

Servers connected by routes do exchange messages sent to temporary topics.AMBZone Z

mhopServer AServer MServer BRouting : Propagating SubscribersTopic : T1Topic : T1Topic : T1GLOBAL TOPICGLOBAL TOPICGLOBAL TOPICSubscriber : T1Subscriber : T1Subscriber : T1Producer : T1Subscriber : T1CLIENTCLIENT

Routed QueuesHow is routing in queues different from that in topics?

Servers route queue messages between the queue owner and adjacent servers.

The concept of zones and hops does not apply to queue messages (only to topic messages).Routed QueuesIn routing topics, the declaration of the topic is identical on all servers

Queue declarations make a distinction between the server that owns the queue and other servers with routed queues that reference both the queue name and the owning serverPRSServer PServer RServer SRouted QueuesQ1 @ R : globalQ1 : globalQ1 @ R : globalQ1Producer AStore & forward to RProxy ReceiverHOME QUEUEProxy ReceiverQ1Consumer BQ1Consumer CQ1Consumer D

The message is NOT available for consumers until it reaches the HOME QUEUERouted QueuesRouted queues serve as proxies for the real queue

Messages published to the proxy queue are forwarded to the real queue, and are not eligible for delivery until they reach the real queue

?