Evaluation of Design Choices

The comparison between the design alternatives can be abstracted in a feature matrix. Choice 1, 2 and 3 refer to position of server-filter mappings in separate CORBA object providing a mapping service, in BOA daemon (micod) and in server object respectively as described in the previous section.

Table 1: Feature matrix

Overheads	Design Choices
	1 2 3
Plug/Unplug	High Low High
Method invocation without filters	High High Low
Method invocation with filters	High High High

We observe that all three choices are capable of supporting both essential and extended properties of filter objects. Hence the distinguishing factor between these choices is overheads incurred by each of them. We have considered two main types of overheads viz. plug/unplug overhead and method invocation overhead, with and without plugged filters. These form the basis of comparison aided by feature matrix shown in Table 1.

In choice 1, where client-filter mappings are stored in a mapping service, both the overheads are high. In this case, every plug/unplug beta message and method invocation has to consult the mapping service. This naturally results in higher overheads. In case of choice 2, mappings are maintained in the BOA daemon, micod. This choice reduces plug/unplug overhead since these beta messages are sent to the daemon instead of a mapping service. However the method invocation overhead increases even for normal method calls. Whenever a method invocation occurs, it has to pass through micod, which checks for the plugged filters and forwards the call accordingly. This clearly leads to higher overhead during method invocations even if the server object doesn't have any plugged filters. With plugged filters, routing invocation to them results in additional invocation overheads. With choice 3, where mappings are stored on the server-side, plug/unplug overhead is higher than that in choice 2. This overhead increases since sending these beta messages requires obtaining a server object reference and then invoking these beta operations on it. However, with this approach, there is no penalty on method invocations for objects without plugged filters. The method invocation on server objects with plugged filters results in higher overheads because of method routing to filters, which is unavoidable in all the three cases.

From the above discussion, it is clear that choice 1 has comparatively higher overheads than choices 2 and 3. In case of choice 2, though its plug/unplug overheads are low, method invocation overheads are one the higher side. Since method invocations are more frequent than plug/unplug beta messages, an implementation using choice 2 would lead to higher overall time losses than choice 3. Hence choice 3 better suits the design considerations and was selected for implementation of the filter object framework.