There is an

interesting thread
going on at TheServerSide about EJB 3.0.  Some
people have offered suggestions for the upcoming new specification, and one of
them was interceptors:

You need to be able to restrict access based on what values instance
properties hold. That is how real world systems work. Interceptors – or advices
- would be a good way of implementing this.

While I
initially responded than it would be interesting to have the
specification define interceptors for EJB’s formally, I am slowly changing my
mind.  The more I think about it, the more I believe it would be a bad idea
to add this to the EJB specification.  There are several reasons to this,
which I’ll examine in turn:

  1. Lack of use cases
  2. AOP

Lack of use cases

Interceptors have an undeniable "cool factor".  They make for great
demos and allow you to take peek inside what used to be seen as a magic black
box.  Over the years, I have talked to several customers using EJB
intensively and only a few of them asked for interceptors.  What was
interesting is that when I drilled down and asked them why exactly they wanted
interceptors, it always turned out that their needs could be met through
different means than EJB interceptors (some of them being flags that we already
provided and they didn’t know about, others being telling them about some EJB
lifecycle events they didn’t know about).

However, there were a few cases not covered by any of the above, which brings
me to my second point.

AOP

Since we released our AOP Framework for WebLogic, it’s become pretty clear to
us that AOP can be easily applied to J2EE in general and EJB in particular. 
If you haven’t looked at it yet, it is basically a set of pointcuts defined in
AspectJ that transparently ties into a server.  The interesting thing is
that there is no AOP support in any of the WebLogic Server versions we
support.  The package is totally external, and yet it is able to weave
itself into existing code.

And therein lies its power:  suddenly, all your J2EE applications become
not only potential targets for interception, but these interceptions can be
extremely sophisticated.  As sophisticated as the AOP implementation you
are using, actually (right now, we are using AspectJ).

With that in mind, the importance of specifying interception in the EJB
specification becomes very questionable.  Not only would the specification
be very narrow (it only applies to EJB’s), it would also be very restricted
since dealing only with the container part of the application.  Maybe I
should clarify that.

EJB code is typically made of three parts:

  • User code
  • Generated code
  • Container code

A specification of interceptors would only cover container code. 
Generated and container code will obviously vary depending on the server you are
using.

With that in mind, it’s pretty clear that an official interceptor
specification would fall very short of addressing a broad category of problems.

AOP allows you to address these three aspects, assuming that the framework
you are using supports both callee and caller pointcuts.

Conclusion

I think it would be a mistake to make interceptors part of the EJB
specification.  Something more general is needed, both in scope (it should
apply to J2EE and not just EJB) and conceptually (use aspect-oriented
programming on top of the existing technologies).