Support for interceptors between blocks

See the Phoenix Issue PNIX-15 for some more data. There is also the start of this work in spice-xinvoke but maybe we should look at using some other interceptor toolkit if we can find one that does not also try to be "aspect" toolkit

Comments imported from PNIX-15:

Currently Phoenix will Proxy the service interfaces of all components unless explicitly asked not to. As a result no client will ever have a direct reference on another object.

This gives us the ability to insert "Interceptors" in the call for every method. Interceptors allow us to plug in functionality when making an invocation on object.

In EJB servers, Interceptors are used to decorate the calls with specific functionality. You can get Interceptors to

• Manage transaction state (commit, rollback on fail etc).
• Manage security (make sure caller has right permissions, the caller principle is set up and that the method is invoked as the correct subject
• Audit calls (make sure all calls are logged) etc.

Non ejb related interceptors include

• Manage application isolation. (ie make sure the caller context does not interfere with calleds context. This involves setting Context ClassLoader etc).
• Make sure that stale references are not used (ie re-aquire service from pool for call then put back in pool after use)

Usually each call will pass through a interceptor chain where each interceptor is given the opportunity to do something.

Interceptors have to be specially handled as they need to be created before any call can be made against the service. They are also unique in that the interceptor chain may be different dependending on "who" is making the call and what they are making the call on.

For example a component C1, may expose services S1 and S2. When a call is made on S1 from component C2 then Interceptor chain I1 is used, while if C2 made a call on S2 then chain I2 is used. If another component C3 made a call on S1 then I3 may be used.

As you can see this gets very complex, very fast. Because of this we need to define a simple, yet sufficiently capable enough configuration format for these interceptr chains. (If this is even possible)

Interceptors to consider besides the standard lifecycle interceptors;

• Bindings interceptor: Bind a Service (And another interceptor chain?) into a naming system
• Passivation/Activation Interceptor: Serialize object to disk and then deserialize to use when required again
• Remoting Interceptor: Remote objects service interface (and interceptor chain?) via RMI, AltRMI, SOAP etc.
• Sub component Interceptor: Interceptor that activates and builds
  sub-components
• JMX Interceptor: Registers component as MBean

interceptors should be standardized throughout the system