Topics:
For more information JMQ notification, see the following topics:
The Oracle Communications Messaging Server notification plug-in enables you to deliver notification messages to a messaging service or event service. The messaging service sends the notifications to consumers (client interfaces), which filter and deliver the messages to specified users.
For example, when new email arrives in a user's mailbox, the notification plug-in delivers a notification message to the messaging service. The message consumer, a component of the messaging service, receives the notification and sends it to the user's email client (such as Convergence or Mozilla Thunderbird). The email client can then display a pop-up on the user's computer screen: "You have received a new message."
Another example: if a user's mailbox exceeds its quota, the notification plug-in produces an over-quota notification message. The message consumer sends a warning to the user and to an administrator who needs to be informed of the event.
You can configure Messaging Server to deliver notifications to two different messaging services:
Oracle GlassFish Message Queue
Event Notification Service
The Message Queue service implements the Java Messaging Service (JMS) specification, providing a message broker, interfaces to create clients that produce or consume messages, and administrative services and control. Message Queue follows the JMS standard for routing and delivery functions, protocols, and message formats.
The Event Notification Service is a component bundled with Messaging Server and Calendar Server. It is a proprietary service that uses a publish/subscribe architecture for sending and receiving event notifications.
You can configure a notification producer for Message Queue, for the Event Notification Service, or for both services.
Note:
This information describes how to configure notifications for Message Queue only.For information about the Event Notification Service, see:
Note:
ENS and JMQ event notification services are "best effort" network services. A best effort network service does not provide any guarantees that the data is delivered. More specifically, under high load situations, ENS and JMQ silently discard notifications. In addition, setting JMQ transport to "reliable" does not prevent notifications from being silently discarded. In fact, "reliable" mode may actually increase the load on the JMQ broker and thus increase the chances for dropped notifications.To enable Messaging Server to produce notifications to Message Queue or the Event Notification Service, you must configure a plug-in for that service:
The JMQ notification plug-in enables you to deliver notification messages to the Message Queue broker.
The iBiff plug-in allows you to publish notification events to the Event Notification Service.
For information on how to load the iBiff plug-in and configure the Event Notification Service, see "Administering Event Notification Service."
The JMQ notification plug-in, with Message Queue, provides the following benefits:
Message Queue implements the JMS standard.
With Message Queue, you can produce messages to a topic or a queue, or to both of these delivery methods. For a brief definition, see "Publishing to a Topic or a Queue."
Message Queue offers enhanced load balancing during message distribution, especially when messages are produced to a queue.
The JMQ notification plug-in allows you to configure up to five notification plug-ins. The different plug-ins can produce messages to a topic, to a queue, to the Event Notification Service, and so on. For details, see "Using Multiple JMQ Notification Plug-ins."
You can configure notifications conditionally for a specific set of users instead of automatically sending notifications for all users, greatly reducing the total number of messages sent.
You can configure notifications for different sets of users to be sent to different Message Queue systems, enhancing the scalability of the notification service.
Message Queue provides reliable delivery of notifications. For example, if you configure the JMQ notification plug-in to produce messages with the persistent flag enabled, the message remains in the Message Queue broker until a consumer receives it. The message is saved so that, if a server goes down, the message can be retrieved and made available to the appropriate consumer.
The following sections describe these benefits in more detail:
A topic and queue use different messaging delivery patterns. Each one can be configured in a Message Queue service.
Topic. When a message producer sends a message to a topic, a publish/subscribe architecture is used. In this broadcast pattern, a producer sends a message to a topic destination. Any number of consumers can be subscribed to this topic destination. Each consumer subscribed to the topic gets its own copy of the message. If no consumers are subscribed to the topic, the message is discarded.
The Event Notification Service also uses a publish/subscribe architecture. It is similar to the topic pattern defined in Message Queue.
Queue. When a message producer sends a message to a queue, a point-to-point architecture is used. In this pattern, a producer sends a message to a queue destination from which only one consumer can receive it. If several consumers are waiting for messages from the queue, only one subscriber will receive the message. If no consumers are waiting, the message is held until either the message times out, or a consumer expresses an interest in the queue.
Producing messages to a queue allows you to spread the message load across multiple consumers.
You can configure from one to five notification plug-ins.
The libjmqnotify notification plugins are built-in. In Unified Configuration, you use the msconfig command to specify options for a plug-in and to point the plug-in to the library of executable code.
If you specify more than one plug-in, each plug-in produces notification messages independently of the others. For example, if two plug-ins are configured with a delete-message option, and a message is deleted from a user's mailbox, both plug-ins will produce a notification message.
By configuring multiple plug-ins, you can take advantage of different message-distribution patterns for different purposes. For example, you could configure three different plug-ins to produce messages
To a queue (using Message Queue)
To a topic (using Message Queue)
To the Event Notification Service
For each plug-in you configure, you must define a separate set of configuration options.
The options determine two kinds of information:
The kinds of notification messages to produce. For example, enabling the loguser option causes a notification message to be sent whenever a user logs in or out.
Configuration information needed by Message Queue. For example, the jmqhost option identifies the IP address of the host where the Message Queue broker is running.
For instructions on how to configure a plug-in, see "Configuring a JMQ Notification Service (Tasks and Examples)."
Suppose only a few users in your deployment use notifications. For example, you could have a million-mailbox deployment where 10,000 users have voice-mail notifications sent to their inboxes. Enabling notifications for all users would add unnecessary message traffic to the system.
You can configure notifications to be conditional, so that notifications are generated only for the specified users who require them. The conditional use of notifications can greatly reduce the total number of notifications sent, thus reducing the overall load on the system.
To set up conditional notifications, you do the following:
Disable notifications for all users
Enable notifications for those users with the LDAP attribute mailEventNotificationDestination added to their directory entries
Ensure that this LDAP attribute is cached in queued mail messages
When a notification event occurs, Messaging Server looks up the user entry in the directory. If the LDAP attribute is present, a notification is sent to Message Queue. If not, no notification is generated.
For instructions on how to configure this feature, see "To Enable Conditional Notifications for Specified Users."
You can configure notifications for different sets of users to be sent to different Message Queue destinations in a distributed Message Queue environment. For example, for one set of users, notifications can be routed to one Message Queue host. For a second set, notifications can be routed to another Message Queue host.
This feature enhances the scalability of the notification system by distributing notification messages to multiple Message Queue destinations. It operates by extending conditional notifications, described in "Configuring Conditional Notifications for Specified Users." Notifications are produced for users with the LDAP attribute mailEventNotificationDestination in their directory entries. You can associate this attribute with different names; depending on the name, the notification messages are sent to a particular Message Queue destination.
For instructions on how to configure this feature, see "To Configure Conditional Notifications to Be Sent to Different Message Queue Destinations."
Oracle Communications Messaging Server can use Oracle GlassFish Server Message Queue, a standards-based messaging service, to send event notifications. GlassFish Message Queue is provided as a shared component when you install Messaging Server or other Communications Suite products.
This section includes the following topics:
To set JMQ notifications in legacy configurations, you use the string libjmqnotify in the local.store.notifyplugin option. For example, the following command configures the instance name jmq1:
configutil -o local.store.notifyplugin -v 'libjmqnotify$jmq1$'
In Unified Configuration, the local.store.notifyplugin option is replaced with the notifytarget:*.notifytype option, where * is the instance name. Thus, for an instance name jmq1 that uses JMQ as its event notification service, you would set notifytarget:jmq1.notifytype to jmq as in the following example:
msconfig msconfig> set notifytarget:jmq1.notifytype jmq msconfig# write -remark "notifytarget jmq1" msconfig> quit
Note:
The libibiff and libjmqnotify notification plugins are built-in.The following page is a quick-start guide on getting JMQ notifications working along with a sample program to show the output:
The following pages describe how to configure a JMQ notification plug-in to produce messages to be consumed by clients in a Message Queue service: