|
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.