J2EE is a powerful platform. However, we believe that there is one feature missing: the support for ORB interceptors. ORB interceptors (as available e.g., in CORBA) is a piece of code that can be plugged into an Object Request Broker (ORB) to modify how invocations are made. ORB interceptors help to gain agility for applications and to fix many integration issues in a clean way.

The following paper defines interceptors and shows their benefits for concrete J2EE applications and their implementation in the existing J2EE:

http://www.elca.ch/site_repository/resources/InvokersNeedToBeAddedToJ2EE5_2.pdf.

From many discussions with other J2EE architects, we got the impression that interceptors are also a generally requested feature. What do others think?

Do you also think that Sun should add interceptors to the EJB 3.0 specification?

In Linda DeMichael's BOF Session on EJB 3.0, a few people suggested that interceptors should be added. See: TSS' Java One Day 2 Reporting.

But so far it's not under consideration, however, the expert group hasn't been formed yet so it might still come up..

Floyd

Xwork (http://wiki.opensymphony.com/space/XWork) provides an open source generic command pattern framework (i.e. not tied to the Web, or any other context) and one of the most powerful features of XWork is the interceptor support. See http://wiki.opensymphony.com/space/Xwork+Interceptors for docs on XWork Interceptors. Most of the functionality of XWork 1.0 and WebWork 2.0 (a Model2 MVC web framework built on XWork) are supplied in the form of Interceptors which can be applied dynamically through an XML configuration file.

With the risk of getting flamed for this reply (because it mentions JBoss), I'll do so anyway.

1.) JBoss provides this functionality today on both the client and sever side.
2.) The JBoss Dynamic AOP framework is the formalization of this idea applied to POJOs as well as a number of pre-packaged aspects.
3.) I agree that interception would be quite useful as a part of the specification and if so, I'm certain that JBoss would gladly comply. Today, some of our customers find this feature compelling enough to sacrifice portability. It would be nice if they could use interception, without loosing portability.

here it comes.. we are starting again. cover up and guard your self, this thread is in fire :)

> With the risk of getting flamed for this reply (because it mentions JBoss), I'll do so anyway.
>
> 1.) JBoss provides this functionality today on both the client and sever side.
> 2.) The JBoss Dynamic AOP framework is the formalization of this idea applied to POJOs as well as a number of pre-packaged aspects.
> 3.) I agree that interception would be quite useful as a part of the specification and if so, I'm certain that JBoss would gladly comply. Today, some of our customers find this feature compelling enough to sacrifice portability. It would be nice if they could use interception, without loosing portability.

I hate to take anything away from the JBoss people, ;-), but interceptors have been in many CORBA products for sometime. Prior to their standardization in the CORBA spec, vendors such as Visigenic/Inprise/Borland (pick which name) and IONA have provided this feature.

Both client and server side interceptors are available today in BES (J2EE CORBA Based Container). Unfortunately the BES team restricted them to entry points at one stage for performance reasons - not sure if this is still the case.

Is there not a Work Area Service JSR proposal from IBM regarding this feature that would allow the development of better distributed performance management and debugging tools?

<example>
In an early version of JDBInsight there was support for the tracing of calls from client - to container - to database based on Visibroker portable interceptors. A Trace interface was provided that allowed the developer to tag calls which would be picked up by the JDBInsight driver on server (BAS4.5/BES 5.x) entry.
</example>

By the way I don't believe the JBoss group have ever claimed credit for 'Interceptors'. Exposure, maybe?

Thread safely.


William Louth
Product Architect - JDBInsight
www.jinspired.com

Considering Bill Burke's bio (he seems to have worked on IONA's ORB) I doubt they'd claim credit for interceptors -- although it seems they are very familiar with the approach, ever since the CORBA days.

/T

You are correct, the JBoss people certainly don't claim credit for this. In fact, Bill makes a point to mention this whenever he speaks on the subject. As far as I know, however, JBoss is the only application server to provide support for interceptors.

Nathan,


"As far as I know, however, JBoss is the only application server to provide support for interceptors."


Thats the problem with the industry. Open Source projects get the credit for alot of innovation at the moment - this perception could be attributed (in some cases) to the fact they are simply open. JBoss has an educational benefit.


As I have stated above, Borland's many named versions of their J2EE server (IAS, BAS, BES) have support for Portable CORBA Interceptors. I would expect that IONA's product as well as IBM Websphere (PIM) to have support. BEA WebLogic most likely has an interceptor like framework/mechanism its just not 'open' to the public.


William

Borland and Iona have application servers? Just joking of course, but you have to admit they are fairly irrelevant in the scheme of things. If IBM has interceptors I was unaware of it. And heck, they may all have interceptors under the covers, but what good does that do you as a developer?

I do not think that every developer out there needs interceptors. There are times when its handly (tracing, profiling, logging, ext. security) but the chances are that such extensions are already provided. IBM WebSphere has 'sophisticated' tracing capabilities.

Also you can have your own portable interceptor framework if you designed your components with this intention. Again most of the time J2EE developments for the masses is about creating JavaBean classes and not components.

Yes, Borland Application Server has not made the impact it probably deserved. But there is customers out there that do appreciate the product over the more 'relevant' JBoss product. I was with a customer recently that was doing its J2EE development against both products. When they can to pre-production testing they would have gone with JBoss if it had stayed up long enough and performed well. Sadly for them it did not and they had to pay license fees to Borland for BES 5.x. There was some issues (bugs?) with both containers but when it came to raw performance and scalability Borland won.

'Open' to this customer meant free - this is probably the case for 95% of developers.

They did not call in the JBoss team / CDN which might have been able to put some magic flag in the conf that said 'fast=true'.

This is not a 'JBoss' knock, as I have no personal/professional agenda, just telling the truth. Each application server has its strengths and weaknesses.


William

> As I have stated above, Borland's many named versions of their J2EE server (IAS, BAS, BES) have support for Portable CORBA Interceptors. I would expect that IONA's product as well as IBM Websphere (PIM) to have support. BEA WebLogic most likely has an interceptor like framework/mechanism its just not 'open' to the public.
>
I'm pretty sure that Portable Interceptors are only available at the transport level in CORBA. Please correct me if I'm wrong. We can have a different interceptor stack per bean. Even a different stack per-bean/per-client/per-transport.

I know the JBoss had interceptors before Iona's Application Server since they had not yet integrated Orbix2K into their app-server when JBoss had interception. Can't speak for Borland though.

Bill

Info for others =>
http://java.sun.com/j2se/1.4.1/docs/guide/idl/PI.html

Bill,

I would not like this thread to turn into

- JBoss did this before xxxx
- JBoss does this better than xxxx

This does not serve any purpose unless you have a David Banner(?) complex, ;-). I hope I have been cured. The intention of my earlier post(s) was to say that others have done this (been there and felt the joy and pain).

JBoss the OS project - has a good reputation. It has changed the J2EE landscape to some degree in terms of vendor pricing, technology implementation, and speed of delivery. The same could be said of ECperf/SPECJAppServer200x in terms of appserver performance.

The customers I talk with don't really care about which product did this first. If it is not available in all appservers they are reluctant to base their overall architecture design on it. They don't mind writing code specific for a particular product as long as they deliver similiar features across other 'relevant' vendor products.

Lets face it - interceptors is not a tactical design decision but strategic. If you are the only one that has 'developer/design' feature X what leverage does this give the customer. One reason for moving to J2EE is for some degree of portability.

Who benefits from a product specific interceptor support
- performance management vendors?
- security vendors?
- developers who like to play with a new toy?
- educationalist?
- JBoss service organization?

I could be completely wrong as the industry always surpises me, but surely there is still alot of room in the J2EE specifications to improve on the 'ilities' while not vendor locking customer code and designs.

I am still waiting for the day that my partner, Debby, stops laughing over my shoulder when she looks at the current crop of Java/AppServer development tools running on my machine. I know you should not judge a book by its cover (especially when we are talking about IntelliJ, ;-)) but do you not get the feeling somebody has forgotten to do something and simply moved onto the next adrenaline rush...

<aside>
By the way Bill do you have a SPECjAppServer kit that I could use for performance testing JBoss. I have managed to get hold of kits for 2 other products and would love to include JBoss (and before anyone jumps in, yes I know all about benchmarking, but as rough guide I find SPECjAppServer200x sufficient).
</aside>

All the best,

William

http://www.jcp.org/en/jsr/detail?id=149

The Work Area Service allows J2EE developers to set properties as application context that is implicitly attached to and made available anywhere during the processing of remote requests.

I know in Sept 2001 Sun and the other J2EE vendors discussed the introduction of Interceptors. One or two vendors thought that JSR 149 was not required and instead that Intereceptors be added to the RMI-IIOP specification. Yes, this was always going to kill off Interceptors - the great RMI-Build-Your-Own and RMI-IIOP debate.

Personally I would have liked it to be introduced but felt that the developer community was not finished digesting the growing number of J2EE specifications. There was still much more work to be done on the tooling and the platform.

Maybe its time for Interceptors especially with Aspects all the rage. Will this be inline with the 'simplification' currently promoted by SUN et al. Doubt it.


William Louth
JInspired
www.jinspired.com

- an ex-Borlander who once thought that JavaSpaces would be everywhere and anywhere, and here by now

> http://java.sun.com/j2se/1.4.1/docs/guide/idl/PI.html
>
> Bill,
>
> I would not like this thread to turn into
>
> - JBoss did this before xxxx
> - JBoss does this better than xxxx
>
> This does not serve any purpose unless you have a David Banner(?) complex, ;-). I hope I have been cured. The intention of my earlier post(s) was to say that others have done this (been there and felt the joy and pain).
>

Yes. I worked at Iona before and felt the joy. My point was, Portable Interceptors were limited (thanks for the link, they are per-ORB, not per-transport). That JBoss has had interceptors for a long time and approach it in a different more flexible way. (And we're expanding the scope of interception with our AOP framework)

> JBoss the OS project - has a good reputation. It has changed the J2EE landscape to some degree in terms of vendor pricing, technology implementation, and speed of delivery. The same could be said of ECperf/SPECJAppServer200x in terms of appserver performance.
>
> The customers I talk with don't really care about which product did this first. If it is not available in all appservers they are reluctant to base their overall architecture design on it. They don't mind writing code specific for a particular product as long as they deliver similiar features across other 'relevant' vendor products.
>

I don't think interceptors are for the average everyday application. We're seeing the real affect of interceptors with tool vendors and ISVs that want tighter integration. Interceptors are perfect for system-level aspects.

> Lets face it - interceptors is not a tactical design decision but strategic. If you are the only one that has 'developer/design' feature X what leverage does this give the customer. One reason for moving to J2EE is for some degree of portability.
>
> Who benefits from a product specific interceptor support
> - performance management vendors?
> - security vendors?
> - developers who like to play with a new toy?
> - educationalist?
> - JBoss service organization?
>

Cover of June Scientific American. Self-healing machines:

http://www.sciam.com/article.cfm?colID=1&articleID=000DAA41-3B4E-1EB7-BDC0809EC588EEDF

They are using JBoss + our interceptors so that their programs can learn about the behavior of your application and detect when it is sick(among other cool things like micro-rebooting). We are talking to them about incorporating AOP as well. Look for JBoss.org to announce integration with the cool stuff ROC is doing this Fall.

> I could be completely wrong as the industry always surpises me, but surely there is still alot of room in the J2EE specifications to improve on the 'ilities' while not vendor locking customer code and designs.
>

Problem is these specifications move too slow. The Expert committees manytimes work under closed doors under NDAs. The bigger they get the slower the revisions come out. Saw it with the OMG too.

> but do you not get the feeling somebody has forgotten to do something and simply moved onto the next adrenaline rush...
>

I do feel that way (about WebSmurfages in particular). This is why I'm so excited about JSR-175 and AOP. Together they have a real opportunity to simplify development. I've said this before in other threads, its the fundamental architecture that needs to change. A better development tool just hides the real problems.

> <aside>
> By the way Bill do you have a SPECjAppServer kit that I could use for performance testing JBoss. I have managed to get hold of kits for 2 other products and would love to include JBoss (and before anyone jumps in, yes I know all about benchmarking, but as rough guide I find SPECjAppServer200x sufficient).
> </aside>
>

Ask on jboss-dev and jboss-user mail list. Some university kid was porting it awhile back. Ecperf though is available under the 'ecperf' CVS module for 3.0, 'ecperf-3.2' for jboss 3.2 although Ecperf is really a horrible benchmark since it doesn't allow for a cache.

Bill

Hi Bill,

Read the printed article while on a Aer Lingus flight to JavaOne SF (via New York). I thought it was an interesting article though felt there was alot to be resolved especially when J2EE was mentioned. I will reread the article again and see if I missed the detail I required.

Rebooting for a simple process/container is an option but what happens when many external resource managers have to be re-initialized and everything has to get all warm and comfy for the user _population_. Their measurement might not be accurate (its all perception - lazy loading and initialization).

Of course I would assume that they will attempt to 'reboot' smaller parts but this is complicated by the various levels of coupling between systems. Its hard to design systems without some degree of coupling (level,type) that are performant.

Could what they are attempting to do with JBoss, though they did not mention this fact ;-), be solved today (or when J2EE 1.4 is out) through the use of JMX and a pattern language such as rapide (an event pattern language)?

<plug>
I did not manage to get our event pattern language into JDBInsight 2.0 for JavaOne but will aim for the next release. Hopefully when JDBInsight 2.x ships developers will be able to use JUnit to test the transactional semantics of use cases at the resource/component level.
</plug>

Thanks,

William Louth
Product Architect of JDBInsight
www.jinspired.com

Aside from the argumentative facts that: (a) it is possible to implement interceptors on distributed objects in a cross-vendor manner today, rapidly, without adding this to the spec, (b) all EJB containers already implement the interceptor pattern, and what you're really asking for is for the standard to mandate a way of exposing it to developers (in a possibly less-performant manner), and (c) where it is difficult to add interceptors there already is a standard for it (servlet filters)...

... AOP-style interceptors are too young and untested in terms of performance and scalability for Sun to mandate or imply a specific implementation of them in EJB across all critical business cases already implemented out there in the real world, further bloating the spec before the additions are truly enterprise-ready.

To Sun and the JCP: Please don't let competition with .NET Remoting sinks and channels (yuck) and the hacker open source culture's current obsession with AOP-style interceptors affect the mature EJB standard my business currently depends on.

Logan,

Out of curiousity could you eloborate on why you find the .NET approach so distasteful?

Regards,
John

J2EE servers provide transactions, persistence, security and what have you. The whole idea of the architecture is to make programming as linear and as simple as possible. Interceptors break this badly. Just thinking about the "average programmer" doing its own transactions and threading inside the interceptor (which will happen inevitably) gives me the creeps. How interceptors solve any integration issue I fail to see as well. I do not see them helping in any way.

This is probably an idea from people who applauded for printf and enums going to be part of the java language :-).

I agree that it's possible that interceptors can be misused by unaware programmers. However for architects they have proved very useful, and restricting their use only to architects is possible.
That's what we do: We have a J2EE extension framework with interceptors and our architects use interceptors in almost every projet.
Sometimes it's just very useful to add something to the bean invocations coming from an external component (e.g. the content management system mentioned in the interceptor examples).
I agree that the command pattern can be an option for small systems, however it can be unmanageable in large projects (e.g. EJB design pattern book by F. Marinescu). It also seems strange if such a pattern (e.g., command pattern) is required to be added on top of the infrastructure.

Hi,

Interceptors help a lot in the CORBA area. MQSeries knows a similar concept, called exits. Over the time, also in J2EE people realized that this is a helpful feature and we got servlet filters. So, all in all this seems to be a useful pattern. Why does it always take so long to reinvent something that is proven since a decade?

The world is not only J2EE and sometimes you are faced with integration tasks: Did you ever try to integrate a legacy CORBA system into J2EE?
And do not tell me that you have cool things like java2idl. Most of the times the IDL you get is bug-ugly and does not compile with the ORB you are using...

Or how about integrating a traditional transaction server?
It took BEA quite a while to integrate their own TM into WLS...

Some companies use a MQSeries system to communicate with signed messages. How would you receive such messages in a J2EE container so that the session started by the MdB runs in the security context of the end-user who sent the MQSeries message?

For me, interceptors would be an extremly useful extension for J2EE. People can argue a lot about what J2EE is already offering you (security, Tx, etc.). However, have a closer look and be honest: a clean security propagation between J2EE appservers of two different vendors only works since J2EE 1.3. And even there I would be very careful and first check whether it really works. A propagation of transactions does not work. And looking backward at the experience we made with CORBA, I have my doubt that it ever will.

Let's face it. J2EE does a lot for you but only if you are true to the products from one vendor. Does this sound like an open architecture? Do you think it is realistic for an enterprise to have a one-platform-only strategy?
If I could buy a third party Tx-Service that I could install between two different application servers then we might finally get towards a platform independed architecture. Today, you are still tied to the platform of your app-server vendor and when you dare to use more than one product you are in trouble.
Embracing interceptors opens up the architecture. Rejecting them means to stay tied to one vendor.

regards,

einar

[... snip ...]
> From many discussions with other J2EE architects, we got the impression that interceptors are also a generally requested feature. What do others think?
>
> Do you also think that Sun should add interceptors to the EJB 3.0 specification?

IMHO, we need the capability in the Java language. I can think of scenarios where interceptors would be useful in non J2EE environments as well. Interceptors for J2EE would be a special case of Interceptors for Java in general. These are indirectly available by making use of special tools such as nanning or cglib or coding dynamic proxies or for that matter aspectj. However a standardised api would certainly be far more useful. Interceptors are certainly useful and should be incorporated in the spec - but I think they should be available for java and not limited to J2EE.

Yes, I think it's very interesting what one can do with interceptor-like mechanisms in a language (either in the form of "pure" AOP like aspectJ, AOP-frameworks (e.g. like the one in Jboss 4), or with direct language support).

I have one fear that comes up in some tests about AOP on the language level, and that is performance (on the low-level of the language, performance is even more critical). There was a paper on OOPSLA 02 "Performance and Scalability of EJB Applications", which indicates that the use of dynamic proxy-classes of Jboss 3 hurt execution performance significantly for entity beans. Richard Oeberg has some performance concerns with the AOP-framework of Jboss 4.0 ( http://roller.anthonyeden.com/page/rickard ), but it may be possible to fix them.

Philipp

Maybe those features should be added in the RPC level of Java. This is similar for the java implicit context propagation (the CORBA Service context mecanism), all those features are missing on the standard RPC layer of Java (RMI JRMP).

There is a solution for (Portable) Interceptor for pure Java remote objec (JRMP ): CAROL. (http://www.objectweb.org/carol). This solution offers protability (pure java) for remote methods calls interceptions on both client side and server side.

Guillaume

We implemented EJB interceptors (client and server side) that are independent of the EJB container and transparent to the developer (no changes in its code).

Philipp, I agree with you, the next specification should mandate the implementation of interceptors.

But I have some precisions:
- it should be the EJB spec not the J2EE spec.
- it should be an own EJB interceptor, not an ORB interceptor model.

I was developing a lot on Visigenic and took the ORB interceptor principles from there to implement EJB interceptors. But the EJB interceptors are not at the ORB level, they are higher because they must work for any EJB container and they must work without ORB when the invocations are local. The implementation has shown that there is almost no performance penalty (that was my main concern).

Our business need was to enable EJB instance level security and integrate with external pre-existing components. When you set security roles in EJB it's for the bean class not for a single instance. With EJB interceptors it is possible to implement interceptors which propagate any security context from bean instance to bean instance and authorize the invocation (context-based vs. role-based).

The EJB interceptors has been successfully used by a major swiss bank ecommerce platform since 2000.

Regards
Alain Hsiung

Interesting that you also provide interceptors in a separate framework on top of EJB. Do you have more info on your interceptor framework? Ours is discussed in the leaf paper referenced in the white paper.