Per-Process Filters

A per-process filter is code that is associated with a client or server process. The filter monitors all incoming and outgoing method invocations and attribute references that reference objects associated with another process. More than one process filter can be chained together to the same process. There are ten points where code in a filter can be associated with a process: inRequestPreMarshal, outRequestPreMarshal, inReplyPreMarshal, outReplyPreMarshal, inRequestPostMarshal, outRequestPostMarshal, inReplyPostMarshal, outReplyPostMarshal, inReplyFailure, and outReplyFailure. Figure 1 (taken from [4]) illustrates these filter points.

  

Figure 1: Per-process filter monitor points

The name of a filter method indicates where in the method invocation sequence it is invoked. The modifier request or reply indicates whether the filter is associated with the invocation of the method or the reply from the method. The modifier in or out indicates the direction the method invocation or method reply is going with respect to the process with which the filter is associated. In particular, out indicates the invoking object for method invocations and the invoked object for method reply, and in indicates the invoked object for method invocations and the invoking object for method reply. The stem indicates exactly where in the processing of the method invocation the filter is associated: PreMarshal is before parameter marshalling, PostMarshal is after parameter marshalling. Failure is for exceptions. Specifically, code that is associated with failure filter points is executed under two conditions: (1) when an exception condition is raised by the target of the invocation or (2) when there are return values from any preceding filter points indicating that the call is not to be processed any further.

The OrbixWeb abstract class IE.Iona.OrbixWeb.
Features.Filter implements per-process filters. A user-defined filter is implemented by defining a class that inherits from the Filter class. When a process creates an object of this class, the newly-created filter is associated with the creating object's process. Successive filter creation results in these filters being chained in the order of their creation.

The following demonstrates the construction of a per-process filter [4]:

1  public class ProcessFilter extends Filter {
2  public boolean outReplyPreMarshal(Request r)
   {
3   String s, o; 
4   long l = 27;

5   try { 
6    s = ORB.init().object_to_string(
         (r.target()));
7    o = r.operation ();

8    OutputStream outs =
9    _OrbixWeb.Request(r).create_output_stream();
10   outs.write_long (l);

11  } catch (SystemException se) { 
12    System.out.println("Caught exception "+se);
    } 

13  System.out.println ("Request to "+ s);
14  System.out.println ("with operation "+ o);
15  return true; // continue the call
    }
   }

Information about the invocation such as the target, operation name, and arguments can be accessed through the parameter r, which is of type IE.Iona.OrbixWeb.CORBA.Request. For example, the call r.target() in Line 6 of the code above returns the target of the invocation while the call r.operation() in Line 7 returns the name of the operation being invoked.

As mentioned previously, OrbixWeb also allows extra information to be piggybacked onto the method invocation. The call _OrbixWeb.Request(r).
create_output_stream() in Line 9 above creates a stream to which extra information can be written (outs.write_long(l) in Line 12). This information can later be read by the corresponding filter point on the other side of the invocation (in this example, an inReply filter on the client side).