Filter Object Framework for MICO

Introduction

The filtered delivery model of message passing in an object-oriented distributed computing environment provides the separation of message control from message processing in a  transparent manner. In this model, specialized objects called filter objects or simply filters have the ability to filter messages in transit and perform intermediate actions. Few filtering  approaches have been proposed earlier and some implementation are available for  distributed component-based systems.

We have implemented framework for message filtering using transperant dynamically pluggable filter objects with an open-source CORBA implementation - MICO - as the underlying distributed computing architecture. Tools to help build filter objects effortlessly with this framework have been built. This manual documents the development process in evolving the existing system, built using MICO, with the aid of filter objects and aims  at explaining the process to build a new evolutionary system under the new framework.
 

Steps for building filter objects

  • Building filter interface (IDL) from server (filter clients) interfaces.
  • Compiling the IDL into Stubs and Skeletons.
  • Post processing the filter header file.
  • Adding "filtering code" for corresponing filter object methods.
  • Writing BetaFiles and using beta utility.
  • Working with Catalysts.

    •    

    Download

    The source code for MICO with the new filter object framework can be downloaded from ......


     

    USER MANUAL

    Building Filter IDL from Server IDL

    Filter IDL can be obtained from the server IDL in two ways:
    1. By manually writing the code for the IDL complying a set of predefined relationship rules mentioned below.
    2. By using the fidlgen utility.
    Relationship between server and filter interfaces: top

    Compiling the Filter IDL

    Once filter IDL is obtained, it can be compiled using MICO IDL compiler ( idl) to obtain the files defining the filter, the filter stub, and the filter skeleton classes. Note that the current filter framework only intercepts static invocations using the Basic Object Adapter (BOA) on server objects with shared activation policy. Hence idl --no-poa --boa options should be used during compilation.

    top

    Post-processing the Filter Header File

    Post-processing of the filter header file can be done in two ways:

    1. By manually inheriting the filter class (declared in the filter header file) from CORBA::Filter instead of CORBA::Object.
    2. The above task can also be accomplished by using filtergen utility. Along with the filter header file, we also need to supply the filter class name to the utility. The syntax is as given below:
    filtergen <filter header file> <filter class>

    top

    Implementing Filter Objects

    Since filter objects are full-pledged CORBA objects, implementing a filter object is similar to implementing any other CORBA object.

    top

    The Beta Utility and BetaFiles

    BetaFiles are configuration files for using filters.

    Usage: filterconf [NamingAddress] [Address] [-k key] [-f file] [-n | -nc | -nf] [(-e -d -m) | (-p -u)] [-t] [-a] [-h]

    NamingAddress Specifies naming service address. This address must be specified if one of the naming options is used.
    Address
    		 Specifies BOA daemon's address.
    -k key
    		 Use 'key' section in filter configuration file. If it is not specified, first section in filter configuration file is used.
    -f file
    		 Use 'file' instead of default configuration file 'filter.config'.
    -n | -nc | -nf
    		 '-n' option tells filterconf to use naming service for both client and filter. '-nc' and '-nf' options cause filterconf to use naming service only for client or filter respectively. The 'NamingAddress' must be specified if these options are used. Moreover BOA daemon's address might also be requied.
    -e
    		 Use 'Enable' subsection in filter configuration file.
    -d
    		 Use 'Disable' subsection in filter configuration file.
    -m
    		 Use 'Mappings' subsection in filter configuration file.
    -p
    		 Use 'Plug' subsection in filter configuration file.
    -u
    		 Use 'Unplug' subsection in filter configuration file.
    -t
    		 Display time required to send each beta message.
    -a
    		 Use addresses specified in the configuration file.
    -h
    		 Display this message.


    Note:  
    If  -n option is used along with 'Address', 'Address' will be ignored.
    If  -a option is not used, then
        If  -nf option is used along with  -p  or  -u, 'Address' must be specified.
        If -nc option is used, 'Address' must be specified.
        If naming options are not used, 'Address' must be specified.
    If 'NamingAddress' is specified, it must be first argument followed by others in any order.
    Options -e|-d|-m can not be combined with options -p|-u .
     
     

    top

    Working with Catalysts

    Catalysts are processes which manage the filter objects in the system. This involves plugging/unplugging filter objects, mapping filter methods to server methods, and enabling and disabling filter methods selectively. This is achieved using several interfaces provided by the framework.

    Toggling with filter objects:
    Filter objects can be plugged and unplugged from a server object dynamically. This is achieved using the plug and unplug methods of the CORBA::ORB class. Hence before we can plug or unplug filter objects from the system, we need to obtain a local ORB reference. The filter and server object references are passed as parameters.

    Mapping method names:
    Though there are strict rules for filter method signatures with respect to corresponding server method, no such rules exist regarding naming of filter methods. Hence the names filter methods need to be mapped to the corresponding server methods, they are supposed to filter. The upfilter and the downfilter methods of the CORBA::Filter class map the upfilter and downfilter method names to that of the server class. The mappings are established after a filter object is created. Unless the methods are appropriately mapped, filtering action cannot occur even if the filter has been plugged to the server. In such cases the call will continue normally as if no filter exists.

    Toggling with filter methods:
    A filter object can have more than one methods mapped to a single server object method. But at the same time, at the most, only one method can be enabled and acts as a filter method for the corresponding server method. The enable and disable methods of the CORBA::Filter class are provided for this purpose. All the filter methods corresponding to a server method being disabled is semantically equivalent to normal invocation of that server method.
    top