Design Issues and Requirements

Besides seamlessly fitting into the existing MICO framework, the filter design has to meet the following requirements.

• Support basic filtering actions like pass and bounce.
• Support extended filter object properties, like layering and grouping.
• Filter objects need to be transparent to clients as well as servers.
• Evolution of the system using filter objects should involve minimal change (ideally no change) in the existing system code.
• Development process of a system using filter objects should not be radically different from the existing object-oriented development processes.
• Addition of filtering framework into the system should not substantially increase the overheads on the system.
• Granularity of control over filtering actions is also a design issue.
• We assume filters are plugged and unplugged by trusted hosts. Security issues are not considered.

The design alternatives were largely based on two major considerations, the location where the mappings between the server and the filter objects would be held and the point in the actual invocation interaction where the call would be intercepted. On detailed analysis of the implementation model, it was found that the second consideration was dependent on where the mappings would be located. This meant, we only needed to evaluate the choices for locating the mappings between server objects and the filter objects plugged onto them. An analysis led us to three main design alternatives discussed below.

• Choice 1: A CORBA object/service stores the mappings: In this alternative, a service is used to maintain the mappings between server and filter objects. The CORBA object providing this service has a standard interface. This makes it similar to other standard CORBA services. Applications use plug() and unplug() interfaces on this service to plug and unplug filters onto the server objects. Whenever the server receives an invocation, it uses a reference to the mapping service to check for attached filters and take appropriate action. This design would lead to a much higher timing overloads during method invocations.
• Choice 2: Mappings maintained in micod: In this case, we store the filter-server mappings in the micod daemon. Local plug and unplug calls are forwarded to micod for plugging and unplugging filters. Whenever client makes a method invocation, it has to pass through micod, which checks for the filters plugged to servers and forwards the call accordingly. This leads to a substantially higher overhead during method invocation, in case of normal invocation--when no filters are plugged.
• Choice 3: Mappings maintained at the server-side: Here the mappings are maintained in an object in the server-side library. During the method invocation, the presence of plugged filters is checked at the server-side and appropriate action is taken. Overheads on normal method invocation is minimized.