jms-features.md

jms-features.md

Selected JMS features

Non-exhaustive.

Sources:

1. The Java EE 6 Tutorial, Chapter 47
2. TIBCO Enterprise Message Service User's Guide

JMS API

Receiving messages can be sync (explicit call to receive method with optional timeout) or async (register a message listener with consumer).

Queue browser

Able to view the messages inside a Queue that have yet to be consumed. You can browse messages and look at their headers.

(Not available for Topics, whether Durable Subscription or not.)

Local Transactions

Like an SQL transaction, one atomic unit of work, consisting of sends/receives. Either all succeed or all fail.

Temporary Destinations

Temporary queues/topics only last for as long as the connection they are created in.

If producer is asking for a reply, and creates a temporary destination and stays connected, then the consumer can send to it. The temporary destination is gone once the connection is closed.

Message Selectors

Consumer can use a message selector, that tells the JMS provider to filter messages using the properties on the message.

Syntax is SQL-like: NewsType = 'Sports' OR NewsType = 'Opinion'

Message Priority

Range from 0 (low) to 9 (high), with default of 4.

JMS provider will try to deliver based on the priority, but it is not guaranteed to be exact.

Message Expiry

Message will not be delivered after its expiry.

Message Acknowledgment

• AUTO_ACKNOWLEDGE = ack'ed once message is pulled (sync) or sent (async) to the consumer.
• CLIENT_ACKNOWLEDGE = consumer specifically calls acknowledge() on the message. However, this acknowledges all messages in the current session.
• DUPS_OK_ACKNOWLEDGE = lazy ack, so if the JMS provider fails, duplicate messages may be sent to the consumer.

Message Persistence

Whether messages will be lost if the JMS provider goes down. By default, PERSISTENT mode, so won't be lost.

Durable Subscriptions

You know what this is lah.

Tibco EMS

Message Persistence: Reliable Delivery

New mode: RELIABLE_DELIVERY, where server will never tell the producer what happened to the message, even if there is an exception (like due to destination not valid or access denied) that causes 0 consumers to receive the message.

Destination Bridges

Server-based way to get messages sent to one destination, sent to other destinations, regardless of type.

Destination properties

• exclusive: for queues, only allow one primary consumer to receive it, other consumers act as a standby to take over when the primary fails (this is compared to ordinary non-exclusive queues that do round-robin)
• expiration: override expiration time on messages
• flowControl: max size of messages to be stored on server for destination, slow down producers when it is exceeded (by blocking the subsequent calls to send a message)
• maxbytes: max size of messages to be stored on server for destination, reject when past that based on overflowPolicy (discard old or reject incoming messages)
• maxbytes: max number of messages to be stored on server for destination, reject when past that based on overflowPolicy
• secure: check user permissions (don't confuse with SSL). also, server's authorization property must be enabled for this to be effective.

Access Control

Enable server property authorization, and destination property secure where necessary.

You can create users and groups, and use them on access control lists for destinations.

Queue permissions: receive, send, browse
Topic permissions: subscribe, publish, durable, use_durable

SSL

This is available between the EMS client and server. You need to configure a certificate and primary key on the server, in the server config:

listen, ssl_server_identity, ssl_server_key

On the client, you need these jars:

tibcrypt.jar, slf4j-api-1.4.2,jar, slf4j-simple-1.4.2.jar