Introduction To Tibco EMS JMS a~pports these massaging models: Poi nt-to-point(Queues) Publish and Subscribe(Topics) M ulticast(Topics)

Point-to-Point Point-to-point massaging has one producer and one cona~mar per message. This style of messaging uses a queue to store messages until they are receiwd. The message producer sends the message to the queue; the message consumer retriews messages from the queue and sends acknowledgement that the message was recei\ed. More than one producer can send messages to the same queue, and more than one consumer can retriew messages from the same queue. The queue can be configured to be exclusiw, if desired. If the queue is exclusiw, then all queue messages can only be retriewd by the first consumer specified for the queue. Exclusiw queues are useful when you want only one application to receiw messages for a specific queue. If the queue is not exclusiw, any number of receiwrs can retriew messages from the queue. Non-exclusiw queues are useful for balancing the load of incoming messages across multiple receiwrs. Regardless of whether the queue is exclusiw or not, only one consumer can ewr consume each message that is placed on the queue.

Publish and Subscribe In a publish and subscribe massage aystam, producers address massages 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 receiwd by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are recei\ed by all subscribers to the topic. This type of message protocol is also known as broadcast messaging because messages are sent owr the network and receiwd by all interested subscribers, similar to how radio or television signals are broadcast and receiwd.

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 deliwring a copy of the message to each indi\tdual subscriber owr TCP, howewr, the EMS ser.er broadcasts the message owr Pragmatic General Multicast (PGM). A daemon running on the machine with the subscribed EMS client receiws the multicast message and deliwrs it to the message consumer. Multicast is highly scalable because of the reduction in bandwidth used to broadcast messages, and because of reduced EMS ser.er resources used. Howewr, multicast does not guarantee message deliwry 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 mesaages have a standard structure. This structure includes the following sections: Headar(required) Properties(optional) Body( optional) JMS message types: Mesaage: This message type has no body. This is useful for simple ewnt 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 primitiw data type. StreamMesaages: A stream of primitiw values in the Java programming language. Each set of values belongs to a primitiw data type, and must be read sequentially. ObjectMessage: A serializable object constructed in the Java programming language.

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

PERSISTENT when a producer sends a PERSISTENT message, the producer must wait for the ser.er to reply with a confirmation. The message is persisted on disk by the serwr. This deli-..ery mode ensures deli-..ery of messages to the destination on the ser.er in almost all circumstances. Howe-..er, the cost is that this deli-..ery 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 owrhead of persisting the message on disk to improw performance. If authorization is disabled on the serwr, the serwr does not send a confirmation to the message producer. If authorization is enabled on the serwr, the default condition is for the producer to wait for the serwr 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 serwr 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 serwr newr sends the producer a receipt confirmation or access denial and the producer does not wait for it. Reliable mode decreases the "~AJiume of message traffic, allowing higher message rates, which is useful for messages containing time-<lependent data, such as stock price quotations.

Me&&age 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 fi"om the message into the selector string, the string evaluates to true. Consumers can request that the serwr deliwr only those messages that match a selector. The ayntax of selectors Is baaed 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-sensitiw. 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).

ftowControl The flowControl property specifies the target maximum size the serwr can use to store pending messages for the destination. Should the number of messages exceed the maximum, the serwr 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 beha'Jior established by the overflowPolicy property, flowControl newr 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 kilobyte~ megabytes, or gigabytes, respectiwly. For example: ftowControl= 1 OOOKB Means 1000 kilobytes. The ftow_control parameter in tibema:l.conf file must be set to enabled before the value in this property is enforced by the ser.er. 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 sel"'.1ce, such as a Java Naming and Directory Interface (JNDI) server or a Lightweight Directory Access Protocol (LDAP) serwr.

Fault Tolerance:

You can arrange 11800 enterprise message sel"'.1ce ser.er fault tolerant operation by configuring pair of ser.ers - one primary and backup. The primary ser.er accepts client connection, and interacts with clients to deliwr messages. If primary fails, backup server resumes operation on its place.

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

Locking:

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

Configuration Files:

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

Detection:

The backup ser.er detects the failure of primary ser.er in either two ways: 1. Heartbeat failure: the primary ser.er sends heartbeat messages to backup ser.er to indicate that it is still operating. When a network failure stops the ser.ers from communicating each other, the backup ser.er detects the intenuption in the steady stream of heartbeat.

2. Connection failure: The backup sero.er detects its failure of TCP connection with primary sero.er. When the primary process terminates unexpectedly, the backup serwr detects the broken connection.

Heartbeat Parameters

When the primary sen.er heartbeat stops, the backup sen.er waits for its activation inter.el (elapsed time since it detected the most recent heartbeat); then the backup ser.er retrieleS information from shared storage and assumes the role of primary sen.er.

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

Shared State:

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

Configuring Fault-Tolerant Sen.ers To configure an EMS ser.er as a fault-tolerant backup, set these parameters in its main configuration file (or on the sen.er command line): · Ser.er Set this parameter to the same sen.er name in the configuration files of both the primary serwr and the backup serwr. · ft_actiw In the configuration file ofthe primary ser.er, set this parameter to the URL of the backup ser.er. In the configuration file of the backup sero.er, set this parameter to the URL ofthe primary sero.er

Authorization and Fault-Tolerant Sero.ers EMS authorization interacts with fault tolerance. If authorization is enabled and the two EMS Serwrs are configured for fault tolerance, then both serwrs in a fault-tolerant pair must be configured as follows: · The tibemsd.conf file for each sen.er must haw the same ser.er name and password (the sero.er and password parameters must be the same on each sen.er}. · The user name and password in the users.conf file for each sen.er must match the wlues of the sen.er and pass'NOrd parameters in the tlbemsd.conf file.

If the t'NO EMS sen.ers are not sharing a users.config file, make sure that you create a user with the same name as the EMS sen.er, and set the user's password with the wlue of the ·sen.er" pass'NOrd.

Configuring Clients for Fault-Tolerant Connections

When a backup sen.er assumes the role of the primary sen.er during

failowr, 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 ser.ers 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 haw 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 ser.er as tcp: //ser.er0:7222, and the second server as tcp://server1 :7344 (if first server is not available), you can specify:

ser.erUrl = tcp://ser.er0:7222, tcp://ser.er1 :7344

Routes

libco Enterprise message seNce ser.ers can route messages to other ser.ers

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