The Community OpenORB - NotificationService

Olivier Modica

Shawn Boyce


Table of Contents

Introduction
1. Overview
2. Compilation
3. Installation
4. Configuration
5. Deployment
How to launch the Notification Service examples
6. Frequently Asked Questions
A. Appendix

Introduction

This document provides all information on how to download, install, run and test the OpenORB NotificationService.

Chapter 1. Overview

The OpenORB Notification Service (Notify) is a fully compliant implementation of the Notification Service specified by the Object Management Group.

The Notification Service extends the Event Service by adding to it several new capabilities. As the events types were Anys and Typed when using the Event Service, the Notification Service allows to transmit events in the form of a well-defined data structure. Clients can now specify exactly which events they are interested in receiving, by attaching filters to each proxy in a channel. The event types describing the events required by all consumers of a channel can be discovered by suppliers of that channel, so that suppliers can produce events on demand, or avoid transmitting events in which no consumers have interest.

The event types offered by suppliers to an event channel can be discovered by consumers of that channel so that consumers may subscribe to new event types as they become available. Several quality of service properties can be set on a per-channel, per-proxy, or per-event basis. These properties configure events and channels persistence, delivery policies as well as object creation policies.

Chapter 2. Compilation

The OpenORB Notify distribution contains an Ant script. Several jars are required, if you use the build.bat (for windows) or build.sh (for unix) all required dependencies and classpath settings are provided.

Thus, to compile the OpenORB Notify, we advise you to enter the following from the command line : build jar (for windows) or sh build.sh jar (for unix). You will find the openorb_notify-x.y.z.jar file in the lib directory. To build the Notify examples, use the following command : build jar-examples (for windows) or sh build.sh jar-examples (for unix). You will find the openorb_notify_examples-x.y.z.jar file in the lib directory.

Chapter 3. Installation

This chapter explains how to install the Notification Service on your system.

We remind you that the OpenORB, and the Persistent State Service distributions are required and must be installed before proceeding to the next steps.

To get the Notification Service, visit the OpenORB website (http://openorb.sf.net). Then, go to the download section. Follow the instructions to download the Notification Service.

Chapter 4. Configuration

When you want to use the Notification Service, the module Notification Service must be included in the runtime profile.

The notify.xml is provided in the config directory of your OpenORB Notification Service distribution. The configuration will be automatically loaded by OpenORB, however if you want to customize it you may do so and then use setConfig.bat (under Windows) and sh setConfig.sh (under Unix) or build config to update the configuration.

        <module name="notify">

            <import xlink:href="${openorb.home}config/pss.xml#pss" />

            <import xlink:href="${openorb.home}config/default.xml#iiop" >
                <property name="port" value="2005" />
            </import>

            <property name="maxQueueLength" value="100"/>
            <property name="maxConsumers" value="100"/>
            <property name="maxSuppliers" value="100"/>

            <property name="logEventQueue" value="false" />
            <property name="logFilterEvaluation" value="false" />

            <property name="eventQueuesPolicy"          value="MaxResource" />
            <property name="suppliersThreadPolicy"      value="MaxResource" />
            <property name="supplierAdminsThreadPolicy" value="MaxPerformance" />
            <property name="consumersThreadPolicy"      value="MaxResource" />
            <property name="consumerAdminsThreadPolicy" value="MaxPerformance" />

            <property name="loggingPriorityLevel" value="fatal" />

            <property name="pullThreadLatency" value="250" />
            <property name="pushThreadLatency" value="250" />
            <property name="adminPushThreadLatency" value="250" />

        </module>
        

The property ORBPort specifies the port the server will be running on. Specifying this property allows to enforce persistence of the server in case of failure/recovery. The user should make sure the specifie port is not in use by another process. Default is 2005.

The property maxQueueLength is a QoS property and specifies the maximum number of events that can be present in the channel at a given time. If that number of events is reached, the suppliers won't be able to send events to the channel.

The property maxConsumers is a QoS property and specifies the maximum number of consumers that can be connected to the channel at a given time. If that number of consumers is reached, new consumer clients won't be able to connect to the channel.

The property maxSuppliers is a QoS property and specifies the maximum number of suppliers that can be connected to the channel at a given time. If that number of suppliers is reached, new supplier clients won't be able to connect to the channel.

The property eventQueuesPolicy is a admin policy and specifies the way the event queues should be managed into the channel. If set to MaxResource the event queues will consume less memory but it will be less performant. If set to MaxPerformance the event queues will be more performant but will consume more memory.

The property suppliersThreadPolicy is a admin policy and specifies the way the threads are managed on the supplier side. If set to MaxResource the proxy consumers (connected to the supplier clients) won't create a thread. This setting should be used when many suppliers can be connected to the channel. If set to MaxPerformance a thread will be dedicated to manage the proxy consumers (connected to the supplier clients). This setting should be used when maximum performance is required and a oneway behaviour is expected from the send methods.

The property supplierAdminsThreadPolicy is a admin policy and specifies the way the threads are managed within the supplier admins. If set to MaxResource the supplier admins won't create a thread. This setting should be used when many admin groups are managed by the channel. If set to MaxPerformance a thread will be dedicated to manage the supplier admins. This setting should be used except when many supplier admins are managed by the channel.

The property consumersThreadPolicy is a admin policy and specifies the way the threads are managed on the consumer side. If set to MaxResource the proxy suppliers (connected to the consumer clients) won't create a thread. This setting should be used when many consumers can be connected to the channel. If set to MaxPerformance a thread will be dedicated to manage the proxy suppliers (connected to the consumer clients). This setting should be used when maximum performance is required.

The property consumerAdminsThreadPolicy is a admin policy and specifies the way the threads are managed within the consumer admins. If set to MaxResource the consumer admins won't create a thread. This setting should be used when many admin groups are managed by the channel. If set to MaxPerformance a thread will be dedicated to manage the consumer admins. This setting should be used except when many consumer admins are managed by the channel.

The property logPriorityLevel allows to specify the logging traces level used by the logger. Acceptable values are debug, error, info, warn and fatal. Default is error.

The properties logEventQueue and logFilterEvaluation allow to specify the use of logging traces in the event queues and filters. Acceptable values are true and false. Using true will be helpful for debugging purposes when performance is not a priority. Default is false.

The properties pullThreadLatency, pushThreadLatency and adminPushThreadLatency define the time while the threads will be in waiting state within the server between two processing.

The pullThreadLatency and pushThreadLatency properties apply respectively to the pull and push models proxies, while the adminPushThreadLatency property applies to the admins (supplier, consumer, channel).

Setting the value to a lower level will lower processing time of an event but will increase CPU consumption. Value is in milliseconds. Default is 250.

Chapter 5. Deployment

How to launch the Notification Service examples

To launch the examples, you first have to launch

  • the Naming Service: java org.openorb.util.MapNamingContext -ORBPort=2001 (port depending on the configuration)
  • and the Notification Service server: java org.openorb.notify.Server
On Unix systems it is recommended to use the launcher scripts tns and notifysvc instead of the above commands, as they will configure the correct classpath settings.

Several examples are included in the distribution that demonstrate the main specification features. More examples will be added in the future.

The simple examples use the Push/Pull model for structured events. Servers and clients are included.

Push supplier example : java org.openorb.notify.examples.simple.StructuredPushSupplier

Pull supplier example : java org.openorb.notify.examples.simple.StructuredPullSupplier

Push consumer example : java org.openorb.notify.examples.simple.StructuredPushConsumer

Pull consumer example : java org.openorb.notify.examples.simple.StructuredPullConsumer

The applications perform several operations and display the results.

Chapter 6. Frequently Asked Questions

Set

6.1. ?
6.1.

?

!

Appendix A. Appendix