path: root/lib/cosNotification/doc/src/ch_system.xml

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2000</year><year>2016</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at
 
          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.
    
    </legalnotice>

    <title>The Notification Service Components</title>
    <prepared>Niclas Eklund</prepared>
    <docno></docno>
    <date>2000-04-13</date>
    <rev></rev>
    <file>ch_system.xml</file>
  </header>

  <section>
    <title>The Notification Service Components</title>
    <p>This chapter describes the Notification Service Components and how they
      interact.</p>

    <section>
      <title>Components</title>
      <p>There are seven components in the OMG Notification Service architecture. 
        These are described below: </p>
      <marker id="notificationFlow"></marker>
      <image file="notificationFlow.gif">
        <icaption>
Figure 1: The Notification Service Components.</icaption>
      </image>
      <list type="bulleted">
        <item><em>Event Channel:</em> acts as a factory for Administrator objects.
         Allows clients to set Administrative Properties.</item>
        <item><em>Supplier Administrators:</em> acts as a factory for Proxy Consumers.
         Administrators are started as <c>'AND_OP'-</c> or <c>'OR_OP'-</c>type,
         which determines if events must be validated using both the Administrators
         associated Filter and/or its Proxy children Filters.</item>
        <item><em>Consumer Administrators:</em> acts in the same way as Supplier Administrators
         but handle Proxy Suppliers.</item>
        <item><em>Consumer Proxy:</em> is connected to a client application. Can be
         started as <c>Pull</c> or <c>Push</c> object. If the proxy is Push style
         the client application must push events to the Proxy, otherwise the Proxy is
         supposed to Pull events. The <c>CosNotification::AdminProperties</c> is
         used to set the pacing interval.</item>
        <item><em>Supplier Proxy:</em> Acts in a similar way as the Consumer Proxy, but
         if started as a <c>Push</c> proxy it will push events to the client
         application.</item>
        <item><em>Filters:</em> used to filter events. May be associated with Proxies
         and Administrators.</item>
        <item><em>Mapping Filters:</em> used to override events Quality of Service
         settings. Can only be associated with Consumer Administrators and
         Proxy Suppliers.</item>
      </list>
      <p>When a Proxy is started it is set to accept <c>CORBA::Any</c>, 
        <c>CosNotification::StructuredEvent</c> or <c>CosNotification::EventBatch</c>
        (a sequence of structured events).</p>
      <p>If a Proxy is supposed to deliver structured events to a client application
        and receives an <c>CORBA::Any</c> event, the event is converted to a 
        structured event with <c>type_name</c> set to <c>"%ANY"</c> and the
        event is stored in <c>remainder_of_body</c>.</p>
      <p>If a Proxy is supposed to deliver <c>CORBA::Any</c> events to a client application
        and receives a structured event, the event is stored in an Any type. The
        Any Type Code will be equal to the <c>CosNotification::StructuredEvent</c>
        Type Code.</p>
    </section>
  </section>
</chapter>