Introduction to VisiNotify

This chapter provides a general discussion on the architecture of the Object Management Group (OMG) Event/Notification Service and introduces Micro Focus's implementation, VisiNotify.

Note

It is recommended that you use this document in conjunction with the application examples shipped with VisiNotify and the OMG Event/Notification Specification that is available on the OMG web site http://www.omg.org/.

OMG Event/Notification Service Communication Model

In the CORBA environment, the core ORB is a distributed framework for creating object-oriented client/server applications. The communication model(s) supported by the core ORB is intended for the client/server applications with direct (at least conceptually), one-to-one, synchronous communication. Some of the application requirements go beyond the core ORB facility, such as:

•	Support for distributed publish/subscribe application design, such as, many-to-many and de-coupled.

•	Support for single directional, asynchronous and buffered event distribution with a throughput substantially higher than synchronous communication.

•	Support for quality of services (QoS), such as event/connection reliability.

•	Support for event filtering.

The requirements mentioned above have been supported by traditional message oriented middleware (MOM) for non-CORBA applications. OMG Event/Notification Service addresses the same set of requirements for CORBA applications.

In publish/subscribe applications, objects involved in the communication could be arbitrary. There are two types of objects in publish/subscribe communication; the event suppliers (providers and publishers) and event consumers (observers and subscribers). Also, there are two event transfer models; the event pushing and event pulling. Objects involved in the publish/subscribe communication are de-coupled from each other by the message middleware. These objects are not dependent on the existence and status of other objects in order to work properly. Event suppliers transfer events to the channel regardless the existence of consumers.

Note

De-coupling in this instance means independence rather than security. If a supplier can tell, implicitly, the existence of a consumer, it does not mean de-coupling is broken.

In single directional event distribution, events flow from upstream into downstream. Specifically, events flow from suppliers to channels and subsequently flow from channel into subscribed consumers. Event transfer is asynchronous and buffered. Suppliers can get acknowledgment from the message middleware, not from the consumers. This means event transfer routing through a message middleware could have much higher throughput than synchronous method invocation without routing.

OMG Event/Notification Service Object Model

The main concept in OMG Event/Notification is the channel. Events are sent into an event channel and replicated to their recipients. Multiple independent channels can be created and used by a given application. Events are either pushed or pulled into an event channel from the supplier. The events flow inside the channel in a downstream direction. Events in the downstream end are buffered in proxy suppliers and are pushed to or pulled by consumers. Application level event suppliers or consumers are connected with proxy objects to transfer events into/from the channel.

In the downstream end of a channel (consumer end):

•	Each push consumer needs to create and connect to a dedicated proxy push supplier. It then passively waits for the channel callback to send events.

•	Pull consumers actively invoke requests on proxy pull suppliers to retrieve events from the channel.

Proxy suppliers are usually located in the channel server and are created by applications from consumer admins. Consumer admins are created either as a default or by applications from channels. Each channel has a default consumer admin. This creation process forms a [channel]-[consumer(s) admin(s)]-[supplier proxy(s)] hierarchy.

In the upstream end of a channel (supplier end):

•	Push suppliers actively invoke requests on proxy push consumer to push events into the channel.

•	Each pull supplier needs to create and connect to a dedicated proxy pull consumer. It then passively waits for channel callback to retrieve events.

Proxy consumers are usually located in the channel server and are created by applications from supplier admins. Supplier admins are created either as a default or by applications from channels. Each channel has a default supplier admin. This creation process forms a [channel]-[supplier(s) admin(s)]-[consumer proxy(s)] hierarchy.

This diagram illustrates the event flow (upstream and downstream) within the notification communication model:

Like most traditional message oriented middleware, the OMG Notification Service also defines and supports Qualify of Services (QoS). VisiNotify supports most OMG defined QoS policies along with additional VisiNotify extensions. Among those QoS policies, two most important QoSs are event persistence and connection persistence. With event persistence (or reliability), buffered events in the channel are temporarily stored in a persistent repository to prevent event loss due to maintenance shutdown or accidental system crash. With connection persistence (or reliability), OMG defines two QoS functions. The first function is that images of channels, admins, proxies and their current settings are stored in a persistent repository that allows the channel server to restore these objects upon channel restart. The second function is that the channel can reestablish transport connections to pull suppliers and push consumers.

Another important service defined by the OMG Event/Notification Service is event filtering. Applications can add filter objects at admin or proxy level to selectively filter out unwanted events.

The OMG Event/Notification Service defines four types of notification channels; the untyped, structured, sequence, and typed. The event interfaces of the first three channels are pre-defined by OMG Event/Notification specification and are referred to as “pre-defined” channels. The event interfaces for typed channels are not pre-defined by OMG but by user applications and are referred to as “user-defined” typed channels. VisiNotify supports all four types of channels with the exception of the sequence pulling.

With the untyped channel, events are represented as CORBA Anys. Events are sent by invoking push() operation with CORBA::Any as an input parameter using untyped consumer or proxy untyped consumer objects. With structured and sequence channels, events are represented as StructuredEvent IDL structures or sequence. Events are sent by invoking push_structured_event() or push_structured_events() on the respective consumer or proxy consumer. With a typed channel, there is no predefined event interface. Event interfaces are defined by user applications as OMG IDL interfaces. Events are sent by invoking non-pseudo operations on consumers’ or proxy consumers’ typed interfaces.

Note

Examples of supplier and consumer applications with the above event types are discussed in “Developing supplier and consumer applications”.

VisiNotify features

Micro Focus VisiNotify is an industrial-strength implementation of OMG Event/Notification Service. Instead of implementing on the user level, VisiNotify is implemented on ORB level and registered with the Naming Service using the generic Naming Service mechanism. See the “Using the VisiNaming Service” chapters in the VisiBroker for Java and VisiBroker for C++ Developer’s Guides for more information. With this unique design, VisiNotify is able to work more efficiently and to provide features that are difficult or impossible to support on the user level. Here are the main features of VisiNotify.

Superior throughput and scalability

VisiNotify is designed to work at the GIOP message level. It directly hands over received event payloads to the downstream consumers. When replicating any received events, VisiNotify does not de-marshal events unless there are filters or event level QoS in the stream. And VisiNotify does not re-marshal events even if there are filters or event level QoS. This unique design allows VisiNotify to reach a very high event throughput with a very low CPU usage. On handling client connect through GIOP 1.0 and 1.1, advanced techniques are used to adjust payload alignment without de-marshaling and re-marshaling the events.

By leveraging Micro Focus's event buffering/batch technology in VisiBroker 5.1, the throughput displayed by VisiNotify is substantially higher in magnitude than any user level notification service product on the market. The use of event buffering and batch processing optimizes VisiNotify throughput. Different from user level batch technology, (such as sequence event) the event buffering/batch technology is fully transparent to user applications and has no restrictions on event type. All event types (untyped, structured, sequence or typed) can be buffered/batched. Therefore, VisiNotify is able to reach the best end-to-end event throughput by combining event batch with the smallest event sizes and lowest event marshaling/de-marshaling cost of typed events.

With user level implementation, event buffering/batch is not transparent to the application. Also, only restricted event types, namely structured events, can be sent in batches. Compared to Micro Focus's event buffering/batch technology, event batch using sequence channel has no advantages. Therefore, VisiNotify only provides limited support for sequence channel with the following restrictions:

•	Support for only end-to-end push model sequence channel. Filter constraints and event level QoS policies are only evaluated for the first event in a sequence and the result is applied to the entire event.

•	Maximum batch size setting is ignored.

•	Sequence pulling is not supported.

Note: a real industry usage case (ITU-T CORBA/TMN notification) based throughput benchmark test suite is shipped with this VisiNotify release. See <install_dir>/examples/vbroker/notify/bench_[itut|tmf]_cpp and bench_[itut|tmf]_java.

Superior performance with event persistence

Many user level channel products use DynAny to unpack event from events for persistence support. VisiNotify directly dumps event message payloads into persistent storage without de-marshaling and unpacking them. This unique design minimizes the overhead from event persistence. Under the default setting, VisiNotify event persistence overhead is 5% to 15%.

Valuetype support

VisiNotify is the first and only notification channel that supports valuetypes in events. Even with the presence of a filter in the event stream, VisiNotify can still evaluate filter conditions using the attributes before the first valuetype in a given event.

Typed channel support

The typed channel support is documented in “Developing supplier and consumer applications”.

VisiNotify is the first OMG Typed Event/Notification implementation that does not use Dynamic Invocation Interface (DII) and Dynamic Skeleton Interface (DSI). VisiNotify does not rely on Interface Repository to work unless there is a filter constraint in the typed event stream. This means that VisiNotify's typed channel is significantly faster than any typed or untyped channel implementations.

Since VisiNotify does not rely on the IR when filter is not used, the key parameters used in calling obtain_typed_..._consumer/supplier() are not necessarily to be the event interface repository id. Therefore, applications can choose the proxy keys as an alternative filtering strategy. Applications can use proxy keys to divide a given typed channel into multiple logical channels. This approach is more efficient and flexible than the constraint language parsing based filtering.

Publish/Subscribe Adapter (PSA)

The Publish/Subscribe Adapter feature is documented in“Using the Publish Subscribe Adapter (PSA)”.

The PSA is a programming model and software component supported by VisiBroker (from version 5.1 onwards). It works on top of any OMG Event/Notification Service. The basic concept of the PSA is to provide a high level object-oriented abstraction for publish/subscribe communication. The PSA not only simplifies the code of typed event/notification applications and provides an elegant solution for typed pulling, it shields the application from directly dealing with the connection interface difference. Without PSA, using different event types (untyped, structured, sequence and typed) or transfer models means different connection interfaces.

Typed pulling without using Pull<I> interface

One elegant feature of the PSA is that it supports typed pulling using the original user-defined <I> interface instead of the mangled Pull<I> interface.

Explicit RMI and EJB support

The explicit RMI and EJB support is documented in “Developing supplier and consumer applications”.

VisiNotify supports two types of RMI/EJB connection scenarios. The first scenario is the typed event RMI/EJB applications using VisiNotify's typed channel as a message middleware. In this case, user defined RMI interface or EJB remote interface is the definition for the typed event interface. All suppliers are RMI applications making RMI call to push events into VisiNotify typed channel. All connected consumers are also RMI applications with their RMI reference connected to the typed event channel.

The second scenario involves using the structured event channel. In this scenario, all suppliers are CORBA applications sending CosNotification::StructuredEvent to the structured event channel. In the downstream end, some consumer applications can be a CORBA application connected as structured consumers while others are consumers that can be structured event EJB beans. A structured event EJB bean is no different from a normal session or entity bean. A structured event bean and its remote interface implements and declares a push_structured_event() operation with org.omg.CosNotification.StructuredEvent as input parameter. VisiNotify provides a utility, subtool, to connect a structured event bean's remote interface to a given VisiNotify structure event channel.

These two scenarios provide alternative and pure object-oriented solutions for event driven J2EE applications. Comparing to Java Message Service (JMS) and Message Driven Bean (MDB), the advantages are:

•	Static type safe RMI stubs and skeleton perform message pack/unpack

•	Event are described by user defined Java RMI interface.

Connection persistence

VisiNotify supports the connection persistence as defined by the OMG specification:

•	Restore persistent channels, admins and proxies after channel restart.

•	Reestablish broken/lost transport connections to push consumers or pull suppliers.

VisiNotify restores persistent channel, admin and proxy as well as their current settings and IDs (ChannelID, AdminID and ProxyID). VisiNotify also reestablish transport connections. VisiNotify also supports an extended feature that automatically put a proxy on suspended state if the connection to the connected push consumer or pull supplier is broken. This is a better scenario than trying to reestablish the transport connection in a loop.

Self-adaptive asynchronous flow control

In OMG Notification Service 1.0, the channel should pull for event messages from a pull supplier when there is at least one consumer in the event stream. In OMG Notification Service 1.3, OMG requires the proxy to pull regardless whether any consumers are connected to the channel. The argument made from OMG is, that this pulling of events will shield the supplier from its consumers by preventing the supplier from knowing whether any consumers are present.

These two scenarios could lead to system and network resource waste on the unnecessary and tight pulling. However, with self-adaptive asynchronous flow control, the proxy pull consumer will only pull when returned events can be handed over to at least one consumer in the downstream. This implementation requires that each logic channel is assigned a voting slot. An upstream proxy pull consumer only pulls when the count in its voting slot is non zero. Each downstream proxy supplier, either push or pull, has one vote to its logic channel's voting slot. It votes to pull when the number of events in its queue is lower than the low watermark. And it withdraws its vote when pending events in its queue are more than the high watermark. This avoids the upstream proxy pull consumer pulling events back only to be discarded or rejected by downstream proxy consumers immediately. By setting the high and lower watermark, applications can also get OMG Notification Service 1.0 or 1.3 behaviors.

QoS and filter support

VisiNotify supports OMG QoS and VisiNotify extensions. Also, VisiNotify provides a highly optimized and OMG compliant filter support for structured, sequence, and typed channels. See “Setting the Quality of Service and Filters”.

Thread on demand

Internally, channels and active proxies (proxy pull consumer and proxy push supplier) all require threads. However, threads are not assigned to them as a dedicated servant. They are recycled when other objects above them (hierarchically) are in an idle state. VisiNotify provides threads dynamically.