Orbacus Notify supports all standard QoS and Admin properties. It introduces ways to overcome the shortcomings inherent in the Notification Service specification. These address the following issues:
On a wider scope, you can configure Orbacus Notify to provide maximum performance under various system configurations, ranging from a few suppliers and consumers to many external clients. Orbacus Notify can also be tuned based on competing requirements, such as event reliability and event throughput.
Structured events are classified in the event header by domain and type. Orbacus Notify clients can use this information to ensure unwanted events are never produced in the first place.
Each notification channel maintains an aggregate list of ‘offered’ event types and ‘subscribed to’ event types. Suppliers can add or remove types from those being offered, while consumers may add or remove subscriptions. Any change to the total event offering is passed on to consumers, while subscription changes are passed on to event suppliers.
Event suppliers and consumers can communicate events, regardless of whether or not they are the same type. Orbacus Notify fully supports event translation, where events are ‘minimally enveloped’ according to consumer requirements. Specifically, structured events from a structured supplier are delivered to untyped consumers in a CORBA::Any. Similarly, untyped events are presented to structured consumers within the remainder-of-body field of a structured event.
Orbacus Notify supports the official push and pull delivery models, as well as hybrid combinations.
Orbacus Notify is fully backwards compatible with the OMG Event Service, providing a smooth migration path for your existing event service clients.
To maintain backwards compatibility with event service clients, Orbacus Notify supports untyped event delivery. In addition, Orbacus Notify introduces structured event and sequence structured event delivery.
Structured events enable you to specify per event QoS and compose events consisting of filterable and opaque fields. As structured events are actual IDL types, the filterable fields are visible to Orbacus Notify and are used during event filtering.
For small, individual events, the per-method command overhead may impact overall performance. If your clients frequently transfer small events, you may want to consider using sequence structured events.
In this scheme, one or more structured events are batched together and transferred in a single method invocation. Suppliers have full control of sequence composition and can accumulate a random number of events before actual delivery. Likewise, for consumers, Orbacus Notify enables you to configure the maximum batch size and pacing interval for event delivery.
Structured events are composed of an event header and event body, where the body consists of filterable and non-filterable fields. Through the use of mapping filters, Orbacus Notify supports the mapping of event header lifetime and priority property values. In effect, this mapping changes the way in which the event is handled within Orbacus Notify.
Forwarding filters enable you to filter event flow at various points throughout the service. This ensures that valuable network bandwidth on the consumer side is used purposefully and not by unwanted events.
