lace. Doing this allows keeping the authorization logic separate from the business logic in the component the client is using.
Interceptors could also be used to manage the state of the destination object. An interceptor might stand in for the object itself, allowing a client to believe the object still exists when it has actually deactivated. Doing this allows building much more scalable applications, and it is very similar to what the Microsoft Transaction Server (MTS) does today. In fact, Microsoft plans to restruct
ure MTS using interceptors when COM+ is available. An interceptor could even perform load balancing, transparently distributing method calls to various equivalent objects in turn.
By placing specific attributes in the client code, the client can determine which interceptors load when using a particular COM+ object. But, despite their convenience, interceptors suffer from one potential drawback: performance. Having to traverse a sequence of interceptors on every method call to an object is bound to slow things down.
Microsoft's expectation is that interceptors will primarily be for system-level functions: for the most part, a few highly optimized COM+ objects will be the most commonly used choices. Still, there are likely to be many situations where the convenience and flexibility of interceptors outweigh the performance hit they bring.
illustration_l
ink (17 Kbytes)

Interceptors in the path can check client security, stand in for the object, or perform other tasks, but they increase the call's overhead.