CORBA Notification Service API Reference

This topic includes the following sections:

Introduction

The BEA Tuxedo CORBA Notification Service supports two application programming interfaces. One is based on the CORBA-based Notification Service as defined by the CORBAservices: Common Object Services Specification. This interface is referred to in this document as the CosNotification Service interface. The other interface, called the BEA Simple Events interface, is a BEA proprietary interface designed as an easier to use alternative.

Both interfaces pass structured events as defined by the CORBA-based Notification Service specification and are compatible with each other; that is, events posted using the CosNotification Service interface can be subscribed to by the BEA Simple Events interface and vice versa.

Before using the Notification Service APIs, consider the following topics:

Quality of Service

To determine the persistence of the subscription and whether or not events delivery is retried following a failed delivery, subscribers specify a Quality of Service (QoS). There are two Quality of Service settings: persistent and transient Quality of Service (QoS). The QoS is a property of the subscription.

Persistent Subscriptions

Persistent subscriptions provide strong guarantees about event delivery and the permanence of the subscription. Persistent subscriptions do come with a cost, however, as they consume more system resources (for example, disk space, CPU cycles, and so on), and require more administration (such as managing queues and detecting dead subscribers).

Persistent subscriptions exhibit the following properties:

Transient Subscriptions

Transient subscriptions provide the best performance with the least overhead and exhibit the following properties:

The subscription is in effect until a failed event delivery is detected. On detection of a failed delivery, the subscription is terminated. Normally, the Notification Service, for performance reasons, does not check whether it successfully delivered an event to a transient subscriber. However, occasionally, when the Notification Service delivers an event to a transient subscriber, it checks whether or not the event was successfully delivered. If it was not successfully delivered and the CORBA::TRANSIENT exception is not returned, the Notification Service assumes that the subscription has gone away and cancels the subscription. If the Notification Service receives the CORBA::TRANSIENT exception when an attempt to deliver fails, it assumes that the subscriber is busy and discards the event, but it does not cancel the subscription.

The automatic cancellation of dead transient subscriptions provides a cleanup mechanism for transient subscribers that forget to unsubscribe. Note, however, that the Notification Service checks for successful delivery the first time it sends an event to a subscriber, but does not perform it again until five minutes have elapsed and it delivers another event. Therefore, the interval between checks is at least five minutes, but will be longer if there is no event to deliver when five minutes have elapsed. The minimum interval of five minutes is fixed and cannot be changed. Therefore, event delivery failure is not necessarily detected on the first failed delivery attempt. It is only detected when the Notification Service checks.

Obtaining the Channel Factory

The Channel Factory is used by event poster applications and subscriber applications to find the event channel. The event channel is then used to post events and to subscribe, or create subscriptions, and unsubscribe, or cancel subscriptions.

Notification Service applications use the Bootstrap object to obtain an object reference to the event channel factory. This is done by using the Tobj_Bootstrap::resolve_initial_references operation. The Bootstrap object supports two service IDs for Notification Service applications, NotificationService and Tobj_SimpleEventsService. The NotificationService object is used in applications that use the CosNotification Service API. The Tobj_SimpleEventsService object is used in applications that use the BEA SimpleEvents API.

Using Transactions

The behavior regarding transactions is the same for the BEA SimpleEvents API and the CosNotification Service API. The only operation that supports transactional behavior is push_structured_event, which is supported by the CosNotifyChannelAdmin::StructuredProxyPushConsumer and Tobj_SimpleEvents::Channel interfaces. All other operations can be used in the context of a transaction, but work the same regardless of whether they are executed in a transaction or not.

The behavior when posting an event is tied to the QoS of the subscription. If an event is posted in the context of a transaction, and the event delivery QoS of the subscription is persistent, the delivery will be affected by the outcome of the transaction; that is, if the transaction is committed, the Notification Service attempts to deliver the event to subscribers as it normally would. If the transaction is rolled back, then the Notification Service does not attempt to deliver the event.

If an event is posted in the context of a transaction, and the event delivery QoS of the subscriber's subscription is transient, one attempt will be made to deliver the event, regardless of the transaction outcome. That is, the transaction has no effect on whether the event is delivered or not, and one attempt will be made to deliver the event.

Note: There is no transaction context associated with event delivery. However, in the case of persistent subscriptions, once the poster's transaction commits, the Notification Service guarantees that the event will be delivered to the subscriber or put on the error queue to await administrative action.

Structured Event Fields, Types, and Filters

Figure 2-1 Structured Event

Designing Events

The design of events is basic to any notification service. The design impacts not only the volume of information that is delivered to matching subscriptions, but the efficiency and performance of the Notification Service as well. Therefore, careful planning should be done to ensure that your Notification Service will be able to handle your needs now and allow for future growth.

Listing 2-1 Event Design

domain_name = "HEALTHCARE"
type_name = "HMO"
#Filterable data name/value pairs.
filterable_data.name = "billing"
filterable_data.value = 4498
filterable_data.name = "patient_account"
filterable_data.value = 37621

Obviously, the more specific and precise you are in designing the events that you want your Notification Service application to post and receive, the fewer will be the events the Notification Service will have to process. This has a direct impact on system resources and configuration requirements. Therefore, a lot of thought should be given to event design.

Creating FML Field Table Files for Events

You must create Field Manipulation Language (FML) field table files for events only if one of the following capabilities is required; otherwise FML tables are not required.

Table 2-1 Supported CORBA Any Types

Listing 2-2 Data Filtering FML Field Table File

*base 2000

#Field Name       Field #  Field Type    Flags     Comments
#-----------      -------  ----------    ------    --------
billing           1        long            -          -
stock_name        2        string          -          -
price_per_share   3        double          -          -
number_of_shares  5        long            -          -

The following guidelines and restrictions apply to BEA Tuxedo FML field table files:

Interoperability with BEA Tuxedo Applications

Applications that use the BEA Tuxedo CORBA Notification Service are interoperable with BEA Tuxedo applications that use the BEA Tuxedo EventBroker. An application using the BEA Tuxedo Notification Service can post events that are delivered to BEA Tuxedo EventBroker subscribers, and can receive events that have been posted by BEA Tuxedo EventBroker.

To achieve this interoperability, it is necessary to understand the mapping between CosNotification Structured Events and the BEA Tuxedo FML buffer so that the contents of the FML field tables can be coordinated by BEA Tuxedo. There are two cases to consider: posting events that are to be received by BEA Tuxedo applications via BEA Tuxedo EventBroker; and receiving events that have been posted to the Notification Service Event Channel by BEA Tuxedo applications.

Posting Events

For a BEA Tuxedo application to subscribe to events posted by a BEA Tuxedo application, you must understand how a BEA Tuxedo structured event is mapped to FML32 and the event name at posting time. The mapping is as follows:

Receiving Events

The BEA Tuxedo system detects and posts certain predefined events related to system warnings and failures. For example, system-generated events report on configuration changes, state changes, connection failures, and machine partitioning.

In order for a BEA Tuxedo application to receive events posted by a BEA Tuxedo application, it is necessary to understand how a FML buffer containing a BEA Tuxedo event is used to fabricate a BEA Tuxedo structured event. It is also necessary to know how the domain_name and type_name are related to the BEA Tuxedo event name. There are two cases to consider: system events and user events.

Note that BEA Tuxedo uses a leading dot (".") in the event name to distinguish system-generated events from application-defined events. An example of a system event is .SysNetworkDropped. An example of a user event is eventsdropped. To subscribe to these events, the Notification Service subscriber application must define the subscription as follows:

Parameters Used When Creating Subscriptions

When you create subscriptions, you can specify the following parameters. These parameters support the BEA Simple Events API and the CosNotification Service API.

Listing 2-3 Data Filtering Requirements

//Setting up the FML Table

Field table file.
----------------
*base 2000

*Field Name    Field #   Field Type   Flags    Comments
-----------    -------   ---------    ------   ------
StockName        1        string        -        -
PricePerShare    2        double        -        -
CustomerId       3        long          -        - 
CustomerName     4        string        -        -

//Subscription data filtering.
1) "NumberOfShares > 100 && NumberOfShares < 1000"
2) "CustomerId == 3241234"
3) "PricePerShare > 125.00"
4) "StockName == 'BEAS'"
5) "CustomerName %% '.*Jones.*'" // CustomerName contains "Jones"
6) "StockName == 'BEAS' && PricePerShare > 150.00"

//Posting the event.
// C++
CosNotification::StructuredEvent ev;
...
ev.filterable_data[0].name    = CORBA::string_dup("StockName");
ev.filterable_data[0].value <<= "BEAS";
ev.filterable_data[1].name    = CORBA::string_dup("PricePerShare");
ev.filterable_data[1].value <<= CORBA::Double(175.00);
ev.filterable_data[2].name    = CORBA::string_dup("CustomerId");
ev.filterable_data[2].value <<= CORBA::Long(1234567);
ev.filterable_data[3].name    = CORBA::string_dup("CustomerName");
ev.filterable_data[3].value <<= "Jane Jones";

// Java
StructuredEvent ev;
...
ev.filterable_data[0].name = "StockName";
ev.filterable_data[0].value.insert_string("BEAS");
ev.filterable_data[1].name = "PricePerShare";
ev.filterable_data[1].value.insert_double(175.00);
ev.filterable_data[2].name = "CustomerId";
ev.filterable_data[2].value.insert_long(1234567);
ev.filterable_data[3].name = "CustomerName";
ev.filterable_data[3].value.insert_string("Jane Jones");

BEA Simple Events API

Simplicity and ease-of-use are the defining characteristics of the BEA Simple Events application programming interface (API). Its capabilities are similar to those of the BEA Tuxedo EventBroker.

The Tobj_SimpleEvents::Channel and the Tobj_SimpleEvents::ChannelFactory interfaces are implemented by the Notification Service and are described below.

Note: The CosNotification Service classes referred to in this section are fully described in the CosNotification Service IDL files, which are located in the tuxdir/include directory.

Note: If you use class operations that are not supported, the CORBA::NO_IMPLEMENT exception is raised.

TOBJ_SimpleEvents::Channel Interface

The Channel interface is used:

This interface provides these operations:

The CORBA IDL for this interface:

module Tobj_SimpleEvents
  {
  typedef long   SubscriptionID;
  typedef string RegularExpression;
  typedef string FilterExpression;

  const SubscriptionType TRANSIENT_SUBSCRIPTION = 0;
  const SubscriptionType PERSISTENT_SUBSCRIPTION = 1;

interface Channel
    {
     void push_structured_event(
         in  CosNotification::StructuredEvent   event);

     SubscriptionID subscribe (
       in    string                            subscription_name,
       in    RegularExpression                 domain,
       in    RegularExpression                 type,
       in    FilterExpression                  data_filter,
       in    CosNotification::QoSProperties    qos,
       in    CosNotifyComm::StructuredPushConsumer push_consumer);

     boolean exists( in SubscriptionID id );

     void unsubscribe( in SubscriptionID  id );
    };
  };

These operations are described in the following section.

Channel::subscribe

CORBA IDL

SubscriptionID subscribe (
      in    string                             subscription_name,
      in    RegularExpression                  domain,
      in    RegularExpression                  type,
      in    FilterExpression                   data_filter,
      // The filter expression must length 1 and the name must
      // be TRANSIENT_SUBSCRIPTION or PERSISTENT_SUBSCRIPTION.
      in    CosNotification::QoSProperties     qos,
      in    CosNotifyComm::StructuredPushConsumer push_consumer
);

Parameters

Exceptions

Description

Use this operation to subscribe to events. This operation is called by a subscriber application on the Notification Service to create a subscription to a particular event. The subscription name, domain name, type name, data filter, quality of service, and the object reference of the subscriber's callback object are passed in. The callback object implements the CosNotifyComm::StructuredPushConsumer IDL interface.

Note: For subscribers that shut down and restart, you must write the subscription_id to persistent storage.

Return Value

Note: Notification Service applications that start and shut down only once can use the subscription_id to determine if their subscription has been cancelled automatically or by the system administrator.

Examples

C++ code example:

subscription_id = channel->subscribe(
          subscription_name,
          "News", // domain
          "Sports",   // type
          "",     // No data filter.
          qos,
          news_consumer.in()
        );

Java code example:

Channel::unsubscribe

CORBA IDL

void unsubscribe( in SubscriptionID id );

Parameter

Exceptions

Description

Used to unsubscribe. Subscriber applications use this operation to terminate subscriptions. On return from this operation, no further events can be delivered. There is one input parameter: SubscriptionID, which you got when you subscribed.

Examples

C++ code example:

channel->unsubscribe(subscription_id);

Java code example:

channel.unsubscribe(subscription_id);

Channel::push_structured_event

CORBA IDL

void push_structured_event(
      in   CosNotification::StructuredEvent   notification
);

Parameter

Exceptions

Description

Used by the poster application to post an event to the Notification Service.

Examples

C++ code example:

channel->push_structured_event(notification);

Java code example:

channel.push_structured_event(notification);

Channel::exists

CORBA IDL

boolean exists(in SubscriptionID subscription_id);

Parameter

Exceptions

Description

Used by subscriber applications to determine if a subscription exists. Since the system administrator can delete subscriptions manually and the Notification Service can delete transient subscriptions automatically, a subscriber application might want to use this operation so that it can recreate the subscription, if necessary. The subscription_id used in this operation is the same one that you got when you subscribed.

Return Value

Returns Boolean True of the subscription exists and False if it does not.

Examples

C++ code example:

if channel->exists (subscription_id) {
    // The subscription is still valid.
} else {
  // The subscription no longer exists.

}

Java code example:

if channel.exists (subscription_id) {
    // The subscription is still valid.
} else {
  // The subscription no longer exists.

}

TOBJ_SimpleEvents::ChannelFactory Interface

The ChannelFactory interface is used to find event channels. This interface provides a single operation: find_channel.

The CORBA IDL for this interface:

module Tobj_SimpleEvents
{
  typedef long   ChannelID;

interface ChannelFactory
{
 Channel find_channel(
   in ChannelID channel_id // Must be DEFAULT_CHANNEL
  );
 };
};

Channel_Factory::find_channel

CORBA IDL

Channel find_channel(
      in  ChannelID  channel_id );

Parameter

In this release of BEA Tuxedo, there can only be one event channel; therefore, the ChannelID that is passed in must be set to Tobj_SimpleEvents::DEFAULT_CHANNEL (for C++) or Tobj_SimpleEvents.DEFAULT_CHANNEL.Value (for Java).

Exceptions

Description

Used by poster applications and subscriber applications. This operation is used to find the event channel so that it can be used by the poster to post events and by the subscriber to subscribe and unsubscribe to events.

Return Value

Returns the default event channel's object reference.

Examples

C++ code example:

channel_factory->find_channel(
               Tobj_SimpleEvents::DEFAULT_CHANNEL);

Java code example:

channel_factory.find_channel(DEFAULT_CHANNEL.value);

CosNotification Service API

This section contains a discussion of the operations defined by the CosNotification Service that are implemented by the BEA Tuxedo CORBA Notification Service. These operations are only a subset of the complete set of operations. This subset is a functionally complete API that can be used as an alternative to the BEA Simple Events API.

This API is more complex then the BEA Simple Events API. There are two reasons for this. First, the CosNotification Service API is more complex. Second, the BEA Tuxedo implementation of the CosNotification Service API places additional restrictions on the operations that are supported. Because this complexity offers no advantages in terms of performance or flexibility, BEA Systems, Inc. recommends that you use the BEA Simple Events API whenever possible.

The CosNotification API is provided for those who require that a standard API be used whenever possible for purposes of portability. In regard to functionality, this API provides no benefits beyond those offered by the Simple Events API. Applications that are developed using this API will be mostly, but not completely, portable. The reason for this is that not enough of the CosNotification Service API is supported to facilitate portability. For example, the filtering grammar required by the CORBA-based Notification Service is based on the COS Trader grammar. Since BEA Tuxedo does not support this grammar, but supports an alternative grammar based on the BEA Tuxedo EventBroker grammar, any application that requires filtering will not be portable. The same is true for QoS, that is, the CosNotification Service API does not support the CORBA-based Notification Service standard qualities of service, but it does support alternative qualities of service.

Overview of Supported CosNotification Service Classes

Figure 2-3 Implemented CosNotification Service Classes

Detailed Descriptions of CosNotification Service Classes

This section describes the CosNotification Service classes that this release of BEA Tuxedo implements. These classes are fully described in the CosNotification Service IDL files, which are located in the tuxdir/include directory.

Note: If you use class operations that are not supported, the CORBA::NO_IMPLEMENT exception is raised.

CosNotifyFilter::Filter Class

This class is used by event subscriber applications. The OMG IDL for this class is as follows:

Module CosNotifyFilter
{
interface Filter { 
     ConstraintInfoSeq add_constraints (
             in ConstraintExpSeq constraint)
          raises (InvalidConstraint);

      void destroy();
    };
}; //CosNotifyFilter

CosNotifyFilter::Filter::add_constraints

Synopsis

Sets the domain, type, and data filter parameters on the filter object.

OMG IDL

ConstraintInfoSeq add_constraints (
             in ConstraintExpSeq constraint)
          raises (InvalidConstraint);

Exceptions

Description

Note: The BEA Tuxedo implementation of the add_constraints operation (1) can only be called once, (2) must be called before the filter is added to the proxy object, and (3) must consist of only a single constraint that has a single event type.

Return Value

Returns an empty list, which we recommend that the caller ignores.

Examples

C++ code example:

// set the filtering parameters
// (domain = "News", type, and no data filter)
CosNotifyFilter::ConstraintExpSeq constraints;
constraints.length(1);
constraints[0].event_types.length(1);
constraints[0].event_types[0].domain_name =
    CORBA::string_dup("News");
constraints[0].event_types[0].type_name = 
                CORBA::string_dup ("Sports");
// no data filter
constraints[0].constraint_expr = CORBA::string_dup("");           CosNotifyFilter::ConstraintInfoSeq_var
add_constraints_results = // ignore this returned value
     filter->add_constraints(constraints);

Java code example:

CosNotifyFilter::Filter::destroy

Synopsis

Destroys the filter object.

OMG IDL

void destroy();

Exceptions

Description

Used when unsubscribing. This operation is used in subscriber applications to destroy the target filter object.

Note: Do not destroy the filter object until you are ready to cancel the corresponding subscription.

CosNotifyFilter::FilterFactory Class

This class is used by event subscriber applications. The OMG IDL for this class is as follows:

Module CosNotifyFilter
{
interface FilterFactory {
   Filter create_filter (
          in string constraint_grammar)
      raises (InvalidGrammar);
   destroy();
  }; 
}; //CosNotifyFilter

CosNotifyFilter::FilterFactory::create_filter

Synopsis

Determines which events are delivered to a subscription.

OMG IDL

Filter create_filter (
in string constraint_grammar)
raises (InvalidGrammar);

Exceptions

Description

Used in the subscriber application to create a new filter object. This filter is used to determine which events are delivered to a subscription. The subscriber must set up the filter and add it to the proxy within five minutes; otherwise, the filter will be destroyed. The filter grammar must be set to Tobj_Notification::Constraint_grammar; otherwise, the InvalidGrammar exception is raised.

Return Value

Returns the new filter's object reference.

Examples

C++ code example:

filter_factory->create_filter(
      Tobj_Notification::CONSTRAINT_GRAMMAR
);

Java code example:

CosNotifyChannelAdmin::StructuredProxyPushSupplier Class

This class is used by event subscriber applications. The OMG IDL for this class is as follows:

Module CosNotifyChannelAdmin
{
 interface StructuredProxyPushSupplier : 
       ProxySupplier,
       CosNotifyComm::StructuredPushSupplier {

    void connect_structured_push_consumer (
           in CosNotifyComm::StructuredPushConsumer push_consumer)
         raises(CosEventChannelAdmin::AlreadyConnected,
                 CosEventChannelAdmin::TypeError );
    };
    // The following operations are inherited.
    void set_qos(in QoSProperties qos) 
         raises (UnsupportedQoS);
    FilterID add_filter (in Filter new_filter );
    Filter get_filter( in FilterID filter )
         raises ( FilterNotFound);
    void disconnect_structured_push_supplier();
    readonly attribute ProxyType     MyType;
  };
}; //CosNotifyChannelAdmin

CosNotifyChannelAdmin::StructuredProxyPushSupplier:: connect_structured_push_consumer

Synopsis

Completes a subscription.

OMG IDL

void connect_structured_push_consumer (
in CosNotifyComm::StructuredPushConsumer push_consumer)
raises(CosEventChannelAdmin::AlreadyConnected,
CosEventChannelAdmin::TypeError );

Exceptions

Description

Use this operation when subscribing. This operation is used in subscriber applications to subscribe to events. The push_consumer parameter identifies the subscriber's callback object.

Once the connect_structured_push_consumer has been called, the Notification Service will proceed to send events to the subscriber by invoking the callback object's push_structured_event operation. If the connect_structured_push_consumer has already been called, the AlreadyConnected exception is raised.

Note: You must call set_qos and add_filter before calling connect_structured_push_consumer.

Examples

C++ code example:

subscription->connect_structured_push_consumer(
    news_consumer.in()
);

Java code example:

CosNotifyChannelAdmin::StructuredProxyPushSupplier::set_qos

Synopsis

Sets the QoS for the subscription.

OMG IDL

void set_qos(in QoSProperties qos)
raises (UnsupportedQoS);

Exceptions

Description

Used when subscribing. This operation is used in subscriber applications to set the QoS for the subscription. It takes as an input parameter a sequence of name-value pairs which encapsulates quality-of-service property settings that the subscriber is requesting.

The subscription name is set by constructing a name-value pair, where the name is Tobj_Notification::SUBSCRIPTION_NAME, and the value is a user-defined string.

Examples

C++ code example:

CosNotification::QoSProperties qos;
qos.length(2);
qos[0].name =
    CORBA::string_dup(Tobj_Notification::SUBSCRIPTION_NAME);
qos[0].value <<= "MySubsription";
qos[1].name =
    CORBA::string_dup(Tobj_Notification::SUBSCRIPTION_TYPE);
qos[1].value <<=
    Tobj_Notification::TRANSIENT_SUBSCRIPTION;

subscription->set_qos(qos);

Java code example:

CosNotifyChannelAdmin::StructuredProxyPushSupplier::add_filter

Synopsis

Sets the filter object on the subscriber's callback object.

OMG IDL

add_filter(
      in Filter new_filter
);

Exceptions

Description

Used when subscribing. This operation is used in subscriber applications to set the filter object to the subscriber's callback object. If the application using this operation will be shut down and restarted, the filter_id should be written to persistent storage.

Note: This operation: (1) cannot be called after the subscriber callback object is connected (see connect_structured_push_consumer above), (2) cannot be called more than once, and (3) when it is called, the filter constraint expression must already be present in the filter (see CosNotifyFilter::Filter add_constraints).

Note: Only filters created by the event channel's default filter factory can be added.

Return Value

Returns a filter_id.

Examples

C++ code example:

CosNotifyFilter::FilterID filter_id =
      subscription->add_filter(filter.in());

Java code example:

CosNotifyChannelAdmin::StructuredProxyPushSupplier::get_filter

Synopsis

Gets an object reference to the filter currently associated with the subscriber's callback object.

OMG IDL

Filter get_filter( in FilterID filter )
      raises ( FilterNotFound);

Exceptions

Description

Used when a restartable subscriber wants to unsubscribe. This operation is used in subscriber applications to get an object reference to the filter currently associated with the subscriber's callback object. The FilterID that is passed in must be valid for the subscriber's StructuredProxyPushSupplier object. If the FilterID is not valid for any proxy object associated with the event channel, then a FilterNotFound exception is thrown. The operation is only used by subscribers that shut down and restart.

Restrictions

The following usage restrictions and guidelines apply to this operation:

Return Value

Returns a filter object reference to the filter currently associated with the subscriber's callback object.

Examples

C++ code example:

CosNotify::Filter_var filter = 
     subscription->get_filter( filter_id() );

Java code example:

CosNotifyChannelAdmin::StructuredProxyPushSupplier::
disconnect_structured_push_supplier

Synopsis

Used to unsubscribe.

OMG IDL

void disconnect_structured_push_supplier();

Exceptions

Description

Used by subscriber applications when unsubscribing. This operation is used in subscriber applications to terminate a connection between the Notification Service and the subscriber's callback object.

Note: This operation does not stop event delivery instantaneously. After returning from this operation, a subscriber may continue to receive events for a period of time.

Examples

C++ code example:

subscription->disconnect_structured_push_supplier();

Java code example:

CosNotifyChannelAdmin::StructuredProxyPushSupplier::MyType

Synopsis

Always returns CosNotifyChannelAdmin::PUSH_STRUCTURED proxy.

OMG IDL

readonly attribute ProxyType MyType

Description

Always returns CosNotifyChannelAdmin::PUSH_STRUCTURED proxy.

CosNotifyChannelAdmin::StructuredProxyPushConsumer Class

This class is used by event posting applications. The OMG IDL for this class is as follows:

Module CosNotifyChannelAdmin
{
 interface StructuredProxyPushConsumer : 
       ProxyConsumer,
       CosNotifyComm::StructuredPushConsumer {

    void connect_structured_push_supplier (
          in CosNotifyComm::StructuredPushSupplier push_supplier)
       raises(CosEventChannelAdmin::AlreadyConnected);
    // The following operations are inherited.
    readonly attribute MyType;
    void push_structured_event(
          in CosNotification::StructuredEvent notification ) 
       raises( CosEventComm::Disconnected );
    void disconnect_structured_push_consumer();
   }; 
}; \\StructuredProxyPushConsumer

CosNotifyChannelAdmin::StructuredProxyPushConsumer::
connect_structured_push_supplier

Synopsis

Prepares the Notification Service to receive an event.

OMG IDL

void connect_structured_push_supplier (
          in CosNotifyComm::StructuredPushSupplier push_supplier)
       raises(CosEventChannelAdmin::AlreadyConnected);

Exception

Description

Used by poster applications when posting events. You must call this operation to prepare the Notification Service to receive an event and you must pass in a NIL when you use this operation. The sequence of usage is as follows:

Examples

C++ code example:

proxy_push_consumer->connect_structured_push_supplier(
      CosNotifyComm::StructuredPushSupplier::_nil()
    );

Java code example:

proxy_push_consumer.connect_structured_push_supplier(null);

CosNotifyChannelAdmin::StructuredProxyPushConsumer::
push_structured_event

Synopsis

Posts events to the event channel.

OMG IDL

void push_structured_event(
        in CosNotification::StructuredEvent notification ) 
     raises( CosEventComm::Disconnected );

Exceptions

Descriptions

Used when posting events. This operation is used in poster applications to post events to the event channel.

Examples

C++ code example:

proxy_push_consumer->push_structured_event(notification);

Java code example:

proxy_push_consumer.push_structured_event(notification);

CosNotifyChannelAdmin::StructuredProxyPushConsumer::
disconnect_structured_push_consumer

Synopsis

Stops posting events.<