Introduction To Tibco EMS

JMS supports these messaging models:
Point-to-point(Queues)
Publish and Subscribe(Topics)
Multicast(Topics)

Point-to-Point
Point-to-point messaging has one producer and one consumer per message. This style of messaging uses a queue to store messages until they are received. The message producer sends the message to the queue; the message consumer retrieves messages from the queue and sends acknowledgement that the message was received.
More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you want only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever consume each message that is placed on the queue.

Publish and Subscribe
In a publish and subscribe message system, producers address messages to a topic. In this model, the producer is known as a publisher and the consumer is known as a subscriber.
Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are received by all subscribers to the topic. This type of message protocol is also known as broadcast messaging because messages are sent over the network and received by all interested subscribers, similar to how radio or television signals are broadcast and received.

Multicast
Multicast messaging allows one message producer to send a message to multiple subscribed consumers simultaneously. As in the publish and subscribe messaging models, the message producer addresses the message to a topic. Instead of delivering a copy of the message to each individual subscriber over TCP, however, the EMS server broadcasts the message over Pragmatic General Multicast (PGM). A daemon running on the machine with the subscribed EMS client receives the multicast message and delivers it to the message consumer.
Multicast is highly scalable because of the reduction in bandwidth used to broadcast messages, and because of reduced EMS server resources used. However, multicast does not guarantee message delivery to all subscribers.




Destinations overview:

1. Static: created by EMS administrator.
2. Dynamic: created by Client programs as needed for short-term use.
3. Tempprary: Temporary destinations are ideal for limited-scope uses, such as reply subjects.

EMS supports messages up to a maximum size of 512MB

JMS messages have a standard structure. This structure includes the following sections:
Header(required)
Properties(optional)
Body(optional)
JMS message types:
Message: This message type has no body. This is useful for simple event notification.
Text Message: A Java.Lang.String
MapMessages: A set of name/value pairs.
Bytes Messages: A stream of uninterrupted bytes. The bytes are not typed; that is, they are not assigned to a primitive data type.
StreamMessages: A stream of primitive values in the Java programming language. Each set of values belongs to a primitive data type, and must be read sequentially.
ObjectMessage: A serializable object constructed in the Java programming language.

Message Delivery Modes
The JMSDeliveryMode message header field defines the delivery mode for the message. JMS supports PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. EMS extends these delivery modes to include a RELIABLE_DELIVERY mode.

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

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.
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.
Figure 6 Non-Persistent Message Delivery

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.

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.
The syntax of selectors is based on a subset of the SQL92 conditional expression syntax.
Identifiers
Identifiers can refer to the values of message headers and properties, but not to the message body. Identifiers are case-sensitive.
Basic Syntax
An identifier is a sequence of letters and digits, of any length, that begins with a letter. As in Java, the set of letters includes _ (underscore) and $ (dollar).

flowControl
The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. Should the number of messages exceed the maximum, the server will slow down the producers to the rate required by the message consumers. This is useful when message producers send messages much more quickly than message consumers can consume them. Unlike the behavior established by the overflowPolicy property, flowControl never discards messages or generates errors back to producer.
You can set flowControl using the form:
flowControl=size[KBMBGB]
where size is the maximum number of bytes of storage for pending messages of the destination. If you specify the flowControl property without a value, the target maximum is set to 256KB.
You can optionally include a KB, MB or GB after the number to specify kilobytes, megabytes, or gigabytes, respectively. For example:
flowControl=1000KB
Means 1000 kilobytes.
The flow_control parameter in tibemsd.conf file must be set to enabled before the value in this property is enforced by the server. See Flow Control for more information about flow control.

Connection Factory:
A connection factory is either dynamically created by the application or obtained from a data store by means of a naming service, such as a Java Naming and Directory Interface (JNDI) server or a Lightweight Directory Access Protocol (LDAP) server.



Fault Tolerance:

You can arrange TIBCO enterprise message service server fault tolerant operation by configuring pair of servers - one primary and backup. The primary server accepts client connection, and interacts with clients to deliver messages. If primary fails, backup server resumes operation on its place.

Shared State
A pair of fault tolerant servers must have access to shared state, which consists of client connections and persistent messages. This information is useful for backup server to resume its operation of current connections and messages.


Locking:

To prevent the backup server from assuming the role primary server, the shared state is locked by primary server during normal operation. If primary server fails, then lock is released and the backup server can obtain lock.


Configuration Files:

When a primary server fails, its backup server assumes as primary server and resume operations. Before becoming new primary server, the backup server re-reads all it configuration files. If configuration files are shared by two servers then administrative changes carry from old primary server to new primary server.


Detection:

The backup server detects the failure of primary server in either two ways:
1. Heartbeat failure: the primary server sends heartbeat messages to backup server to indicate that it is still operating. When a network failure stops the servers from communicating each other, the backup server detects the interruption in the steady stream of heartbeat.
2. Connection failure: The backup server detects its failure of TCP connection with primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection.

Heartbeat Parameters

When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then the backup server retrieves information from shared storage and assumes the role of primary server.

The default heartbeat interval is 3 seconds, and the default activation interval is 10 seconds. The activation interval must be at least twice the heartbeat interval. Both intervals are specified in seconds. You can set these intervals in the server configuration files.

Shared State:

The primary server and backup server must share same state. The server state includes three categories of information.
1. Persistent message data
2. Client connection of the primary server
3. Meta data about message delivery

Configuring Fault-Tolerant Servers
To configure an EMS server as a fault-tolerant backup, set these parameters in its main configuration file (or on the server command line):
· Server Set this parameter to the same server name in the configuration files of both the primary server and the backup server.
· ft_active In the configuration file of the primary server, set this parameter to the URL of the backup server. In the configuration file of the backup server, set this parameter to the URL of the primary server




Authorization and Fault-Tolerant Servers
EMS authorization interacts with fault tolerance. If authorization is enabled and the two EMS Servers are configured for fault tolerance, then both servers in a fault-tolerant pair must be configured as follows:
· The tibemsd.conf file for each server must have the same server name and password (the server and password parameters must be the same on each server).
· The user name and password in the users.conf file for each server must match the values of the server and password parameters in the tibemsd.conf file.

If the two EMS servers are not sharing a users.config file, make sure that you create a user with the same name as the EMS server, and set the user’s password with the value of the “Server” password.


Configuring Clients for Fault-Tolerant Connections

When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl).

The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried). If none of the attempts succeed, the connection fails.

For example, to identify the first server as tcp: //server0:7222, and the second server as tcp://server1:7344 (if first server is not available), you can specify:

serverUrl = tcp://server0:7222, tcp://server1:7344

Routes


Tibco Enterprise message service servers can route messages to other servers

1. Topic message can travel from one hop to multiple hops
2. Queue messages travel from one hop to home queue and to one hop from home queue.