Installing cosNotification

## 3 Installing cosNotification

### 3.1 Installation Process

This chapter describes how to install cosNotificationApp in an Erlang Environment.

#### 3.1.1 Preparation

Before starting the installation process for cosNotification, the application Orber must be running.

#### 3.1.2 Configuration

When using the Notification Service the `cosNotification` application first must be installed using `cosNotificationApp:install()` or `cosNotificationApp:install(Seconds)`, followed by `cosNotificationApp:start()`.

Then the Event Channel Factory must be started:

- `cosNotificationApp:start_global_factory()` - starts and returns a reference to a factory using default configuration parameters. This operation should be used for a multi-node Orber.
- `cosNotificationApp:start_global_factory(Options)` - starts and returns a reference to a factory using given configuration parameters. This operation should be used for a multi-node Orber.
- `cosNotificationApp:start_factory()` - starts and returns a reference to a factory using default configuration parameters.
- `cosNotificationApp:start_factory(Options)` - starts and returns a reference to a factory using given configuration parameters.

The following options exist:

- `{pullInterval, Seconds}` - determine how often Proxy Pull Consumers will check for new events with the client application. The default value is 20 seconds.
- `{filterOp, OperationType}` - determine which type of Administrator objects should be started, i.e., `'OR_OP'` or `'AND_OP'`. The default value is `'OR_OP'`.
- `{timeService, TimeServiceObj | 'undefined'}` - to be able to use Start and/or Stop QoS this option must be used. See the function `start_time_service/2` in the `cosTime` application. The default value is `'undefined'`.
- `{filterOp, OperationType}` - determine which type of Administrator objects should be started, i.e., `'OR_OP'` or `'AND_OP'`. The default value is `'OR_OP'`.
- `{gcTime, Seconds}` - this option determines how often, for example, proxies will garbage collect expired events. The default value is 60.
- `{gcLimit, Amount}` - determines how many events will be stored before, for example, proxies will garbage collect expired events. The default value is 50. This option is tightly coupled with the QoS property `MaxEventsPerConsumer`, i.e., the `gcLimit` should be less than `MaxEventsPerConsumer` and greater than 0.

It is possible to define a set of global configuration parameters:

Global Configuration Parameters
Key | Range | Default
type_check | true | false | true
notify | atom() | false | false
max_events | integer() > 0 | 50
interval_events | integer() > 0 | 10000 milliseconds
timeout_events | integer() > interval_events | 3000000 milliseconds

Comments on the table 'Global Configuration Parameters':

type_check
  Determine if supplied IOR:s shall be type checked, i.e. invoking corba_object:is_a/2, or not.
notify
  The given value shall point to an existing module exporting a function (arity 1) called terminated. This operation is invoked when a proxy terminates and the argument is a list containing `{proxy, IOR}`, `{client, IOR}` and `{reason, term()}`. The return value is ignored.
max_events
  If a supplier proxy has not been able to push events to a consumer and the queue exceeds this limit, then the proxy will terminate. For this option to have any effect, the `EventReliability` and `ConnectionReliability` QoS parameters must be set to `Persistent`. For more information, see also the QoS chapter.
interval_events
  The same requirements as for `max_events`. When a supplier proxy detects problems when trying to push events, this parameter determines how often it should try to call the consumer.
timeout_events
  The same requirements as for `max_events`. If the proxy has not been able to contact the consumer and this time-limit is reached, then the proxy will terminate.

The Factory is now ready to use. For a more detailed description see Examples.

Copyright © 1991-2007 Ericsson AB