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
Send Message
Receive Message
Acknowledge
Publish-Subscribe(Topics)
TIBCO EMS Server
Publish Message
Deliver Message
Acknowledge
Subscribe to Topic
Multicast(Topics)
TIBCO EMS Server
Publish Message
Broadcast Message
Subscribe to Message
EMS : An extension to JMS
EMS Extensions to JMS Messages - I
JMS provides 2 delivery modes for messages

PERSISTENT

NON_PERSISTENT

EMS adds the 3
rd
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
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
Message Expiry
Queue
2
OR
JMS_TIBCO_PRESERVE_UNDELIVERED = TRUE
BODY
PROPERTIES
HEADER
SERVER
Undelivered message queue
$sys.undelivered
JMS_TIBCO_PRESERVE_UNDELIVERED = FALSE
BODY
PROPERTIES
HEADER
SERVER
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
Producer
EMS Server
Message
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
Message
Producer
EMS Server
Message
Depending on
npsend_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 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
Producer
EMS Server
Message
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
Send Message
Receive Message
Acknowledge
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
TIBCO EMS Server
Publish Message
Subscribe to Topic
Subscribe to Topic
Subscribe to Topic
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
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
EMS Server
File-based Store
(Default)
Database Store
Pre allocate disk space for
store file
Truncate the file to relinquish
disk space
Mode : Sync or Async
Store messages in DB or not
Properties that
allow the user to
control how
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
TIBCO EMS
Server
Message Message
Confirmation
Acknowledgement
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 up a large number of unacknowledged
messages
Message 1 Message 1
Acknowledgement
# 1,2,3
Message 2 Message 3 Message 3 Message 2
JMS : AUTO_ACKNOWLEDGE
Session is to automatically acknowledge consumer receipt of
messages when message processing has finished
Message 1 Message 1
Acknowledgement 1
Message 2 Message 3
Acknowledgement 3 Acknowledgement 2
Message 3 Message 2
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.
Message 1 Message 1
Acknowledgement
#1,2
Message 2 Message 3
Acknowledgement
#3
Message 3 Message 2
EMS : NO_ACKNOWLEDGE
NO_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.
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.
Message 1 Message 1
Acknowledgement 1
Message 2 Message 3
Acknowledgement 3 Acknowledgement 2
Message 3 Message 2
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

Scope of delivery
Supports concurrent use

Creation
Client programs create it if permitted by server configuration

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
Running this service starts 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
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
channels.conf
tibemsd.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


If number of messages > flowControl
then
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
2 1 5 4 3
prefetch
prefetch

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
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
PARENT CHILD
all parents : none none
any parent :
non-zero numeric value
highest
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



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
Bridging Topic to Multiple Destinations
Bridging Queue to Multiple Destinations
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




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 Server : B
Global Destinations : Topics
Routes forward messages only between global destinations

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
E D
P Q R
T S
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.
Eliminating Redundant Paths with One-Hop Zone
B1 B2
R M
GOAL : Forward messages from B1 and B2 to both M and R
Overlapping Zones
M3 M2
M1 M4
B2 B3
B4 B1
D1 D2
D3 D4
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
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
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