EMS 5.

1
TIBCOs Enterprise Messaging Offering
Message MODELS
JMS Message Models

Point-to-Point (Queues)

Publish Subscribe (Topics)

Multicast (Topics)
Point-to-Point(Queues)

TIBCO EMS Server

Message Queue
Receive Message Message
Producer Send Message Consumers

Acknowledge
Publish-Subscribe(Topics)

TIBCO EMS Server

Subscribe to Topic

Message Topic
Deliver Message Message
Producer Publish Message Consumers

Acknowledge
Multicast(Topics)

Multicast Daemon
TIBCO EMS Server

Broadcast Message tibemsmcd

Multicast
Message Topic
Producer Publish Message

Deliver Message

Subscribe to Message Message

Consumer
EMS : An extension to JMS
EMS Extensions to JMS Messages - I

JMS provides 2 delivery modes for messages

PERSISTENT

NON_PERSISTENT

EMS adds the 3rd delivery mode

RELIABLE_DELIVERY
EMS Extensions to JMS Messages - II

For restriction of acknowledge messages in JMS

NO_ACKNOWLEDGE mode

To restrict acknowledgement in EMS, there are

also

EXPLICIT_CLIENT_ACKNOWLEDGE mode
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode
EMS Extensions to JMS Messages - III

EMS 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 StreamMessage
Can use arrays as well as primitive types for
values
Message STRUCTURE
Message Structure

REQUIRED

HEADER

PROPERTIES

BODY
Message Headers
JMSDestination
Destination to which message is sent.

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

JMSExpiration
Length 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 Headers
JMSPriority
Priority of the message. Larger numbers indicate higher
priority.

JMSMessageID
Unique identifier for a message.

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

JMSReplyTo
A destination to which a message reply should be sent.

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

JMS_TIBCO_CM_PUBLISHER
JMS_TIBCO_CM_SEQUENCE
JMS_TIBCO_COMPRESS
JMS_TIBCO_DISABLE_SENDER
JMS_TIBCO_IMPORTED
JMS_TIBCO_MSG_TRACE
JMS_TIBCO_MSG_EXT
JMS_TIBCO_SENDER
JMS_TIBCO_SS_SENDER
JMS_TIBCO_PRESERVE_UNDELIVERED
Undelivered Message Queue

HEADER
HEADER
Message Expiry

1
PROPERTIES
PROPERTIES
JMS_TIBCO_PRESERVE_UNDELIVERED = TRUE
Undelivered message queue
OR
SERVER JMS_TIBCO_PRESERVE_UNDELIVERED = FALSE
$sys.undelivered
$sys.undelivered
SERVER
BODY
BODY 2
Queue

maxRedelivery
 Message Body

MESSAGE TYPE CONTENTS OF BODY MESSAGE

Message No Body
Text Message Java.lang.String
Map Message Name/Value pairs
Bytes Message Stream of bytes
Stream Message Stream of primitive data types
Object Message Serializable object

EMS supports messages up to a maximum size of 512MB

Message DELIVERY MODES
Persistent
When 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.
Persistent

Message

Message
EMS Server
Producer

Acknowledgement
Non Persistent
Sending 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 Persistent
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.
Message

Message
EMS Server
Producer

Depending on
npsend_check_mode
Reliable Delivery
EMS 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 Message
EMS Server
Producer
Reliable Delivery
When 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 Delivery
In 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 Reviewed

NON_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 Revisited
EMS Persistent Mode Management

Persistent Messages Sent to Queues

Persistent 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.
TIBCO EMS Server

Message Queue
Receive Message Message
Producer Send Message Consumers

Acknowledge

Disk
EMS Persistent Mode Management

Persistent Messages Sent to Topics

Persistent 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 Management

Other
TIBCO EMS Server Consumers

Subscribe to Topic

Message Topic
Producer Publish Message Subscribe to Topic
Durable
Consumers

Subscribe to Topic

Store Fault
Tolerant
Consumers
Persistent Messages & Synchronous Storage

When 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 Storage

What 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.
STORE
 Store

Define
STORES
EMS Server
Stores.conf

WRITES TO

Pre allocate disk space for

store file
Truncate the file to relinquish
File-based Store disk space
Database Store
(Default) Properties that Mode : Sync or Async
allow the user to
control how Store messages in DB or not
server manages
the store file
Default Store Files
File based stores are enabled by default.

Server automatically defines 3 default stores

$sys.nonfailsafe
Server writes messages using asynchronous I/O calls.

$sys.failsafe
Server writes messages using synchronous I/O calls.

$sys.meta
Server writes state information about durable subscribers & fault
tolerant connections.
Message COMPRESSION
Message Compression
TIBCO 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 Compression
Less 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 Compression
Compression specific for individual messages.

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

To set message compression

JMS_TIBCO_COMPRESS to TRUE
Message ACKNOWLEDGEMENT
Message Acknowledgement

Message Message
Message TIBCO EMS Message
Producer Confirmation Acknowledgement Consumer
Server
Confirmation of
Acknowledgement

JMS EMS (JMS + Below mentioned modes)

CLIENT_ACKNOWLEDGE NO_ACKNOWLEDGE
AUTO_ACKNOWLEDGE EXPLICIT_CLIENT_ACKNOWLEDGE
DUPS_OK_ACKNOWLEDGE EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
JMS : CLIENT_ACKNOWLEDGE

Consumer 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 CONSUMER
up a large number of unacknowledged
messages
ACKNOWLEDGES

Message 3
1
2 Message 2
1
3
Message TIBCO EMS Message
Producer Server Consumer
Acknowledgement
# 1,2,3
JMS : AUTO_ACKNOWLEDGE
Session is to automatically acknowledge consumer receipt of
messages when message processing has finished

Message 3
1
2 Message 2
1
3
Message
SESSION
TIBCO EMS Message
Producer ACKNOWLEDGES
Server 1
3
Acknowledgement 2 Consumer
JMS : 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.
LAZY
ACKNOWLEDGEMENT

Message 3
1
2 Message 2
1
3
Message TIBCO EMS Message
Producer Server Acknowledgement Consumer
#1,2
#3
EMS : NO_ACKNOWLEDGE
NO_ACKNOWLEDGE mode suppresses the acknowledgement
of received messages.

After the server sends a message to the client, all

informationS eregarding
ssions cre a t e dmessage
that i n n o - for that consumer is
acknowledge receipt mode
eliminated from the server.
cannot be used to create
cannot be used to create
durable subscribers.
Therefore, there is no need for the client application to
send an acknowledgement to the server about the received
message.
EMS : EXPLICIT_CLIENT_ACKNOWLEDGE

EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE

except it acknowledges only the individual message, rather than
all messages received so far on the session.

CONSUMER
1ACKNOWLEDGES
Message 3
2 Message 2
1
3
Message TIBCO EMS Message
Producer
INDIVIDUALLY
Server 1
Acknowledgement 2
3 Consumer
Server
EMS : EXPLICIT_CLIENT_ACKNOWLEDGE

When 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_ACKNOWLEDGE

EXPLICIT_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 SELECTORS
Message Selectors

A 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.
Destinations
Types of Destinations

Static Destinations

Dynamic Destinations

Temporary Destinations
Static Destinations
Purpose
Allows administrators to configure EMS behavior at enterprise level

Scope of delivery
Supports concurrent use

Creation
Using config files, tibemsadmin or by APIs by administrator

Duration
Until explicitly deleted by the administrator
Dynamic Destinations
Purpose
Provide flexibility to define them as needed for short term use
SERVER
Scope of delivery OFFLINE
DURABLE
Supports concurrent use SUBSCRIBER

Creation
Queue Topic
Client programs create it DYNAMIC
if permitted by server configuration
DESTINATION

Duration
As long as at least 1 client actively uses it
Temporary Destinations
Purpose
Ideal for limited scope usage, like reply subjects (in routing)

Scope of delivery
Supports local use

Creation
Client programs create it

Duration
Explicit deletion by the client or disconnection from the server
Mixed Bag - Destinations
Clients 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 topic
tibemsd TIBCO EMS Server
Starting the EMS Server

W H AT I F t i b e m s d . c o n f I S
L O C ATE D I N S O M E O T H E R
Running this service
FOLD starts
ER? the EMS Server

This service starts tibemsd.exe located in

<EMS HOME>/bin folder

tibemsd.exe reads tibemsd.conf for server settings

Using tibemsd to start EMS server

CAUTION

1. N e e d t o c r e a t e s t o r e s ( . d b
files) manually in
tibemsd.conf.

2. Need to specify the

directory for other config
files(default : bin folder)
in tibemsd.conf
tibemsadmin TIBCO EMS Admin
Starting 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 server
Using set

Parameters in tibemsd.conf
Using time & timeout
Using commit & autocommit
Using compact
Using add
Using remove
Using grant & revoke
Using echo
Destination PROPERTIES
channel
channel
Channel 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

tibemsd.conf

channels.conf
channel
exclusive
exclusive

Available 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
expiration
expiration
If 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
maxbytes
maxbytes
Topics & queues can specify the maxbytes property in the form

maxbytes=value[KB|MB|GB]

FOR QUEUES
maxbytes: 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
maxbytes
FOR TOPICS
maxbytes: 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
maxmsgs
maxmsgs
Topics & 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
maxRedelivery
maxRedelivery
The 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 destination
maxRedelivery
overflowPolicy
overflowPolicy
To change the effect of exceeding the message capacity established by maxbytes
or maxmsgs

overflowpolicy=default|discardOld|rejectIncoming

default

For TOPICS
maxbytes or maxmsgs exceed for a subscriber, that subscriber does not receive

message
No error returned to producer

For QUEUES
New messages are rejected by the server if maxbytes or maxmsgs are exceeded

Error returned to producer

overflowPolicy
discardOld

For TOPICS
Oldest 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 QUEUES
Error returned to producer if maxbytes or maxmsgs are exceeded

Oldest messages are discarded from the queue by the server

overflowPolicy
rejectIncoming

For TOPICS
If 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 QUEUES
Error returned to producer if maxbytes or maxmsgs are exceeded

Newest messages are rejected from the queue by the server

overflowPolicy
Quick Quiz
How 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=rejectIncoming

flowControl
flowControl
Specifies the target maximum size the server can use to store
pending messages for the destination

Unlike overflowPolicy,
If number of messages > flowControl
flowControl never discards
then messages or generates
error back to producer
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 them
flowControl

tibemsd.conf
prefetch
prefetch
Consumer and the EMS Server cooperate to regulate message
fetching through this property

prefetch=value
Value Description
2 or more Never fetches more than specified
number (Auto Fetch)
1 Fetch only if it has no message
(Auto Fetch)
none Disable Auto Fetch.
Cannot be used with
topics or global queues
0 (default) Destination inherits the prefetch value.
Default value for
queues = 5 & topics = 64
 prefetch
prefetch = 5
Now, messages belong to consumer SERVER CONSUMER
5 4 3 2 1

ERROR

$sys.undelivered maxRedelivery = 4
JMSXDeliveryCount = 02
1
3
4
5
JMS_TIBCO_PRESERVE_UNDELIVERED = true JMSRedelivered = false
true
prefetch
2 phases : messages from server to consumer

Fetch Phase
RECEIVE CALL

o Consumer initiates fetch phase by sending a signal to the server

that it is ready for more messages

o Serverresponds by transferring one or more messages and gets

stored in consumer

Accept Phase

o Client code takes a message from the consumer

prefetch
Automatic 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)
prefetch
Automatic Fetch Disabled (prefetch = none)
Even when prefetch = none, a queue consumer can hold a message

Example
A receive call initiates a fetch, but its timeout elapses before
the server finishes transferring the message
This leaves a fetched message waiting in the message consumer
A second receive call does not fetch another message; instead it
accepts the message already waiting
The third receive call initiates another fetch
prefetch
A 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 periods

Call receive with no timeout

Call receive with timeout repeatedly and shorten the interval

INHERITANCE
PARENT CHILD
all parents : none none
any parent : highest
non-zero numeric value
does not set any value default
(5 : queues, 64 : topics)
prefetch
secure
secure
If 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.conf
sender_name
sender_name
Server 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_name
sender_name_enforced
sender_name_enforced
Specifies 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_enforced
store
store
Specifies where the messages sent to this
destination are stored

Configure stores in stores.conf

Stores.conf
> store = myStore

testTopic store = topicStore

Destination BRIDGES
Bridges
Some applications require the same message
to be sent to more than one destination,
possibly of different types.

Example
An 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.
Bridges
Bridges 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 Queue

TIBCO EMS SERVER

Subscriber
Topic
Topic
A.B
A.B
Publisher

Subscriber

Queue
Queue
queue.B
queue.B

Consumer
 Bridging Topic to Multiple Destinations

TIBCO EMS SERVER

Subscriber
Topic
Topic
A.B
A.B
Publisher

Subscriber

Queue
Queue Topic
Topic
queue.B
queue.B C.B
C.B

Consumer Subscriber
 Bridging Queue to Multiple Destinations

TIBCO EMS SERVER

Consumer
Queue
Queue
queue.foo
queue.foo
Sender

Subscriber

Queue
Queue Topic
Topic
queue.B
queue.B C.B
C.B

Consumer Subscriber
Bridges
When 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 bridge
Configured in bridges.conf file
Bridges.conf
[topic:A.B]
queue=queue.B
topic=C.B
selector="urgency in(medium, high)"

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.
ROUTING
Routing
EMS 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 queue
Routing : Basic Operation
Each 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 View
Server : A ROUTE Server : B

Queue :
Queue : Q1
Q1@A

Topic : T1 Topic : T1

G L O B A L TOP I C G L O B A L TOP I C

Topic : T2
 Global Destinations : Topics
Routes forward messages only between global destinations

Server : A Server : B

Topic : T1 Topic : T1

G L O B A L TOP I C G L O B A L TOP I C

Topic : T2 Topic : T2

G L O B A L TOP I C

For TOPICS, the global property must be set on both servers

Unique Routing Path
It 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.

A B C P Q R

D E S T

LEGAL ILLEGAL
(in all zones) (in a multihop zone)
Zones
A 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 Operation
In 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.

A B C
If a message is sent to
the global topic on
If Z1 were a one-hop
server B, the server
zone, B would forward
forwards the message to
the message to A, C & D,
A,C,D,E provided there Zone : Z1
but not to E
are subscribers on those mhop
servers
D E
Eliminating Redundant Paths with One-Hop Zone

B1 & B2 : Producers @ Branch Office

B1 B2 M : Consumers @ Main Office
R : Consumers @ Back Office

M serves consumers that process the

message from branches B1 & B2

R serves consumers that record

Zone : Z2 messages for archiving, auditing &
1hop backup
M R

GOAL : Forward messages from B1 and B2 to both M and R

Overlapping Zones
M3 M2 B2 B3

Zone : India
M4 M1 mhop B1 B4
Zone : Mumbai Zone : Bangalore
1hop 1hop
D1 D2

D4 D3 Zone : Delhi
1hop
Creating Routes
Syntax
create 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.conf
url indicates the other server by the URL
Active & Passive Routes
A 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 Routes
Two 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=url
The url argument is required, so that the server (where the route
is being promoted) can connect to the other server if the route
becomes disconnected
Routed Topic Messages
A server forwards the message along the
routes only when the global property is
defined by the topic
Routed Topic Messages
Topic 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.
Routing : Propagating Subscribers

A M Zone Z B

mhop
Server A Server M Server B

Topic : T1 Topic : T1 Topic : T1

GL O B AL TOP I C G L O B A L TOP I C GL O B A L TOP I C

Subscriber : T1 Subscriber : T1 Subscriber : T1

CLIENT CLIENT

Producer : T1 Subscriber : T1
Routed Queues
How 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 Queues
In 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 server
Routed Queues
P R S

Server P Server R Server S

Q1 @ R : Q1 : global Q1 @ R :
global The message is NOT global
available for consumers
HOME
until QUEUEthe
it reaches
Store & forward HOME QUEUE
to R

Proxy Receiver Proxy Receiver

Producer A Consumer B Consumer C Consumer D

Q1 Q1 Q1 Q1
Routed Queues
Routed 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
?