August 07, 2003
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:
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.
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:
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.
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).Posted by cedric at August 7, 2003 11:45 AM