EMS - Enterprise Message Service.

=========================================
Java Message Service 1.1 (JMS) is a Java framework specification for messaging b
etween applications. Sun Microsystems developed this specification, in conjuncti
on with TIBCO and others, to supply a uniform messaging interface among enterpri
se applications.
JMS
are
The
age

Message Models: JMS is based on creation and delivery of messages. Messages

strutured data that one application sends to another.
creator of the message is known as the producer and the receiver of the mess
is known as the consumer.

The TIBCO EMS server acts as an intermediary for the message and manages its del
ivery to the correct destination. The server also provides enterprise-class func
tionality such as fault-tolerance, message routing and communication with other
messaging system such as TIBCO RV and SmartSockets
Message Producer (EMS client) ---> TIBCO EMS server ---> Message Consumer(EMS Cl
ient)
================================================================================
=============================================================================
JMS supports these messaging models:
1. Point-to-point (queues)
2. Publish and subscribe (topics)
3. Multicast (topics)
1. Point-to-point : messaging has one producer and one consumer per message. Thi
s 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 co
nsumer 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 ca
n only be retrieved by the first consumer specified for the queue. Exclusive que
ues are useful when you want only one application to receive messages for a spec
ific 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 pla
ced on the queue
2.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 publi
sher can be received by many subscribers. Subscribers subscribe to topics, and a
ll 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 mess
ages are sent over the network and received by all interested subscribers, simil
ar to how radio or television signals are broadcast and received.
3.Durable Subscribers for Topics
By default, subscribers only receive messages when they are active. If messages

arrive on the topic when the subscriber is not available, the subscriber does no
t receive those messages.
The EMS APIs allow you to create durable subscribers to ensure that messages are
received, even if the message consumer is not currently running. Messages for d
urable subscriptions are stored on the server as long as durable subscribers exi
st for the topic, or until the message expiration time for the message has been
reached, or until the storage limit has been reached for the topic. Durable subs
cribers can receive messages from a durable subscription even if the subscriber
was not available when the message was originally delivered
When an application restarts and recreates a durable subscriber with the same ID
, all messages stored on the server for that topic are delivered to the durable
subscriber
================================================================================
=============================================================================
Creating a Message Consumer:
----------------------------Message consumers are clients that receive messages published to a topic or sent
to a queue. When working with topics, a Message Consumer is commonly referred t
o as a Subscriber.
A Message Consumer can be created with a "message selector" that restricts the c
onsumption of message to those with specific properties. When creating a Message
Consumer for topics, you can set a noLocal attribute that prohibits the consump
tion of messages that are published over the same connection from which they are
consumed.
Carefully consider the message selectors that are used with queue consumers. Bec
ause messages that do not match a queue consumer s message selectors remains in th
e queue until it is retrieved by another consumer, a non-matching message can ex
perience many failed selectors. This is especially so when queue consumers conne
ct, consume a message, and immediately disconnect.
Multicast
----------Multicast messaging allows one message producer to send a message to multiple su
bscribed consumers simultaneously. As in the publish and subscribe messaging mod
els, the message producer addresses the message to a topic. Instead of deliverin
g 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 mes
sage and delivers it to the message consumer.
Multicast is highly scalable because of the reduction in bandwidth used to broad
cast messages, and because of reduced EMS server resources used. However, multic
ast does not guarantee message delivery to all subscribers
================================================================================
=============================================================================
EMS Destination Features:
-------------------------1. Secure mode of access control at the queue or topic level.
2. set threshold limits for the amount of memory used b the EMS server to store
messages for a topic or a queue and fine-tune the server's response to when the
threshold is exceeded
a. flowcontrol :
b. overflow policy
3. Route messages sent to destinations to other servers
4. Create bridges between destinations of the same or different types to create

a hybrid messaging model for your application. This can be useful if

your app
lication requires that you send the same message to both a topic and a queue.
5. Control the flow of messages to a destination. This is useful when message pr
oducers send messages much faster than message consumers can receive them.
6.Exchange messages with other message services. Queues can receive TIBCO Rendez
vous and TIBCO SmartSockets messages. Topics can either receive or send Rendezvo
us and TIBCO SmartSockets messages.
7.Set queues to be exclusive or non-exclusive. Only one receiver can receive mes
sages from an exclusive queue. More than one receiver can receive messages from
non-exclusive queues.
8. Specify a redelivery policy for queues. When messages must be redelivered, yo
u can specify a property on the queue that determines the maximum number of time
s a message should be redelivered.
9.Trace and log all messages passing through a destination.
10. Include the user name of the message producer in the message.
11. Administrator operations can use wildcards in destination names. The wildcar
d destination name is the parent, and any names that match the wildcard destinat
ion name inherit the properties of the parent.
12.Use the store property to cause messages sent to a destination to be written
to a store file. Set the destination store to store=$sys.failsafe to direct the
server to write messages to the file synchronously and guarantee that messages a
re not lost under any circumstances.
13. Specify that a consumer is to receive batches of messages in the background
to improve performance. Alternatively, you can specify that queue receivers are
to only receive one message at a time. See prefetch
================================================================================
=============================================================================
Administration: EMS provides mechanisms for administering server operations and
creating objects that are managed by the server, such as ConnectionFactories and
Destinations.
1.Configuration files allow you to specify server characteristics
2.Administration tool provides a command line interface for managing the server.
3.Authentication and permissions can restrict access to the server and to destin
ations. You can also specify who can perform administrative activities with admi
nistrator permissions.
4.Configure log files to provide information about various server activity
5.The server can publish messages when various system events occur. This allows
you to create robust monitoring applications that subscribe to these system moni
tor topics
================================================================================
=============================================================================
EMS Extensions to JMS Messages
The JMS specification details a standard format for the header and body of a mes
sage. Properties are provider-specific and can include information on specific i
mplementations or enhancements to JMS functionality
In addition to the EMS message properties, EMS provides a select number of exten
sions to JMS. These are:
1. The JMS standard specifies two delivery modes for messages, PERSISTENT and NO
N_PERSISTENT. EMS also includes a RELIABLE_DELIVERY mode that eliminates some of
the overhead associated with the other delivery modes
2. For consumer sessions, you can specify a NO_ACKNOWLEDGE mode so that consumer
s do not need to acknowledge receipt of messages, if desired. EMS also provides
an EXPLICIT_CLIENT_ACKNOWLEDGE and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that
restricts the acknowledgement to single messages
3. EMS extends the MapMessage and StreamMessage body types. These extensions all
ow EMS to exchange messages with TIBCO Rendezvous and ActiveEnterprise formats t

hat have certain features not available within the JMS MapMessage and StreamMess
age.
TIBCO Enterprise Message Service adds these two extensions to the MapMessage and
StreamMessage body types:
- You can insert another MapMessage or StreamMessage instance as a subme
ssage into a MapMessage or StreamMessage, generating a series of nested messages
, instead of a flat message.
- You can use arrays as well as primitive types for the values.
================================================================================
=============================================================================
JMS Message Structure
JMS messages have a standard structure. This structure includes the following se
ctions:
1. Header (required)
2. Properties (optional)
3. Body (optional)
JMS Message Header Fields: The header contains ten predefined fields that contai
n values used to route and deliver messages
Send or Publish Method
1. JMSDestination
2. JMSDeliveryMode : PERSISTENT,NON_PERSISTENT and RELIABLE_DELIVERY
3. JMSExpiration: Length of time that message will live before expiration.If set
to 0 , message does not expire. The time-to-live is specified in milliseconds.
If the server expiration property is set for a destination, it will override the
JMSExpiration value set by the message producer.
4. JMSPriority: Uses a numerical ranking, between 0 and 9, to define message pri
ority as normal or expedited. Larger numbers represent higher priority.
5. JMSMessageID: Value uniquely identifies each message sent by a provider.
6. JMSTimestamp: Timestamp of time when message was handed off to a provider to
be sent. Message may actually be sent later than this timestamp.
message client
7. JMSCorrelationID :This ID can be used to link messages, such as linking a res
ponse message to a request message. Entering a value in this field is optional.
The JMS Correlation ID has a recommended maximum of 4 KB. Higher values may resu
lt in the message being rejected
8. JMSReplyTo
9. JMSType
JMS provider
10.JMSRedelivered: If this field is set, it is possible that the message was del
ivered to the client earlier, but not acknowledged at that time.
================================================================================
=============================================================================
Message Priority:
-----------------------The JMS specification includes a JMSPriority message header field in which sende
rs can set the priority of a message, as a value in the range [0,9]. EMS does su
pport message priority (though it is optional, and other vendors might not imple
ment it).
When the EMS server has several messages ready to deliver to a consumer client,
and must select among them, then it delivers messages with higher priority befor
e those with lower priority.
However, priority ordering applies only when the server has a backlog of deliver
able messages for a consumer. In contrast, when the server has only one message
at a time to deliver to a consumer, then the priority ordering feature will not
be apparent.

================================================================================
================================================================================
Message Delivery Modes
-----------------------The JMSDeliveryMode message header field defines the delivery mode for the messa
ge. 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 wa
it 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 destinati
on on the server in almost all circumstances. However, the cost is that this del
ivery mode incurs two-way network traffic for each message or committed transact
ion of a group of messages.
NON_PERSISTENT:
Sending a NON_PERSISTENT message omits the overhead of persistin
g 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 mess
ages 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 pe
rformance regardless of the authorization setting.
When using RELIABLE_DELIVERY mode, the server never sends the pr
oducer a receipt confirmation or access denial and the producer does not wait fo
r it. Reliable mode decreases the volume of message traffic, allowing higher mes
sage 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.
In some cases a message published in reliable mode may be disqua
lified and not handled by the server because the destination is not valid or acc
ess has been denied. In this case, the message is not sent to any message consum
er. However, unless the connection to the server has been terminated, the publis
hing application will not receive any exceptions, despite the fact that no consu
mer received the message.
================================================================================
================================================================================
Character Encoding in messages

================================================================================

================================================================================
Message Acknowledgement:
--------------------------The interface specification for JMS requires that message delivery be guaranteed
under many, but not all, circumstances
The JMS specification defines three levels of acknowledgement for non-transacted
sessions:
CLIENT_ACKNOWLEDGE specifies that the consumer is to acknowledge all mes
sages that have been delivered so far by the session. When using this mode, it i
s possible for a consumer to fall behind in its message processing and build up
a large number of unacknowledged messages.
AUTO_ACKNOWLEDGE specifies that the session is to automatically acknowle
dge consumer receipt of messages when message processing has finished.
DUPS_OK_ACKNOWLEDGE specifies that the session is to "lazily" acknowledg
e the delivery of messages to the consumer. "Lazy" means that the consumer can d
elay acknowledgement of messages to the server until a convenient time; meanwhil
e the server might redeliver messages. This mode reduces session overhead. Shoul
d JMS fail, the consumer may receive duplicate messages.
EMS extends the JMS acknowledge modes to include:
NO_ACKNOWLEDGE
EXPLICIT_CLIENT_ACKNOWLEDGE
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
NO_ACKNOWLEDGE mode suppresses the acknowledgement of received messages. After t
he 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 recei
ved message. Not sending acknowledgements decreases the message traffic and save
s time for the receiver, therefore allowing better utilization of system resourc
es
EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE except it acknowledges on
ly the individual message, rather than all messages received so far on the sessi
on.
One example of when EXPLICIT_CLIENT_ACKNOWLEDGE would be used is when re
ceiving messages and putting the information in a database. If the database inse
rt operation is slow, you may want to use multiple application threads all doing
simultaneous inserts. As each thread finishes its insert, it can use EXPLICIT_C
LIENT_ACKNOWLEDGE to acknowledge only the message that it is currently working o
n.
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
------------------A message selector is a string that lets a client program specify a set of messa
ges, 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 t
he server deliver only those messages that match a selector
================================================================================
================================================================================
Synchronous and Asynchronous Message Consumption
The EMS APIs allow for both synchronous or asynchronous message consumption. For

synchronous consumption, the message consumer explicitly invokes a receive call

on the topic or queue. When synchronously receiving messages, the consumer rema
ins blocked until a message arrives.
The consumer can receive messages asynchronously by registering a message listen
er to receive the messages. When a message arrives at the destination, the messa
ge listener delivers the message to the message consumer. The message consumer i
s free to do other operations between messages.
================================================================================
================================================================================