cosNotification

User's Guide

Version 1.2.2

• User's Guide
• Reference Manual
• Release Notes
• PDF
• Top

• Expand All
• Contract All

Chapters

• The cosNotification Application
  • Top of chapter
  • Content Overview
  • Brief Description of the User's Guide
• Introduction to cosNotification
  • Top of chapter
  • Overview
• Installing cosNotification
  • Top of chapter
  • Installation Process
• The Notification Service Components
  • Top of chapter
  • The Notification Service Components
• Filters and the Constraint Language BNF
  • Top of chapter
  • Filters and the Constraint Language BNF
• Quality Of Service and Admin Properties
  • Top of chapter
  • Quality Of Service and Admin Properties
• cosNotification Examples
  • Top of chapter
  • A Tutorial on How to Create a Simple Service

3 Installing cosNotification

3.1  Installation Process

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

Preparation

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

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:

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.