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?
-
Opinion: Interceptors should be added to J2EE (25 messages)
- Posted by: Philipp Oser
- Posted on: June 20 2003 09:34 EDT
Threaded Messages (25)
- Opinion: Interceptors should be added to the J2EE by Floyd Marinescu on June 20 2003 15:33 EDT
- Check out XWork by Jason Carreira on June 20 2003 16:01 EDT
- Opinion: Interceptors should be added to J2EE by Nathan Phelps on June 20 2003 17:26 EDT
- Opinion: Interceptors should be added to J2EE by Talip Ozturk on June 20 2003 17:57 EDT
-
CORBA had this a long time by William Louth on June 20 2003 09:28 EDT
- CORBA had this a long time by Thomas Mattson on June 20 2003 11:29 EDT
-
CORBA had this a long time by Nathan Phelps on June 21 2003 07:54 EDT
-
Awareness by William Louth on June 21 2003 12:56 EDT
-
Awareness by Nathan Phelps on June 21 2003 10:25 EDT
- Interceptors for developers? by William Louth on June 22 2003 06:05 EDT
-
Awareness by Bill Burke on June 22 2003 09:36 EDT
-
Java JDK - Interceptors - Thoughts by William Louth on June 22 2003 11:52 EDT
- JSR 149 Work Area Service by William Louth on June 22 2003 01:12 EDT
-
Java JDK - Interceptors - Thoughts by Bill Burke on June 22 2003 10:52 EDT
- June Scientific American by William Louth on June 23 2003 07:35 EDT
-
Java JDK - Interceptors - Thoughts by William Louth on June 22 2003 11:52 EDT
-
Awareness by Nathan Phelps on June 21 2003 10:25 EDT
-
Awareness by William Louth on June 21 2003 12:56 EDT
-
CORBA had this a long time by William Louth on June 20 2003 09:28 EDT
- Opinion: Interceptors should be added to J2EE by Talip Ozturk on June 20 2003 17:57 EDT
- bloating the standard too early, too often by Logan King on June 20 2003 17:39 EDT
- bloating the standard too early, too often by John Lewicki on June 23 2003 14:10 EDT
- What an outright stupid idea!!! by Karl Banke on June 22 2003 06:45 EDT
- RE: What an outright stupid idea!!! by Philipp Oser on June 22 2003 16:09 EDT
- Why did it take that long...? by hanspeter uebelbacher on June 22 2003 10:35 EDT
- Should it be J2EE or Java ? by Dhananjay Nene on June 22 2003 23:48 EDT
- RE: Should it be J2EE or Java ? by Philipp Oser on June 23 2003 06:02 EDT
- Java RMI (JRMP) Interceptors by riviere guillaume on June 23 2003 04:18 EDT
- we implemented EJB interceptors by alain hsiung on June 25 2003 18:06 EDT
- RE: we implemented EJB interceptors by Philipp Oser on June 30 2003 07:54 EDT
-
Opinion: Interceptors should be added to the J2EE[ Go to top ]
- Posted by: Floyd Marinescu
- Posted on: June 20 2003 15:33 EDT
- in response to Philipp Oser
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 -
Check out XWork[ Go to top ]
- Posted by: Jason Carreira
- Posted on: June 20 2003 16:01 EDT
- in response to Philipp Oser
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. -
Opinion: Interceptors should be added to J2EE[ Go to top ]
- Posted by: Nathan Phelps
- Posted on: June 20 2003 17:26 EDT
- in response to Philipp Oser
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. -
Opinion: Interceptors should be added to J2EE[ Go to top ]
- Posted by: Talip Ozturk
- Posted on: June 20 2003 17:57 EDT
- in response to Nathan Phelps
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. -
CORBA had this a long time[ Go to top ]
- Posted by: William Louth
- Posted on: June 20 2003 21:28 EDT
- in response to Talip Ozturk
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 -
CORBA had this a long time[ Go to top ]
- Posted by: Thomas Mattson
- Posted on: June 20 2003 23:29 EDT
- in response to William Louth
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 -
CORBA had this a long time[ Go to top ]
- Posted by: Nathan Phelps
- Posted on: June 21 2003 07:54 EDT
- in response to William Louth
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. -
Awareness[ Go to top ]
- Posted by: William Louth
- Posted on: June 21 2003 12:56 EDT
- in response to Nathan Phelps
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 -
Awareness[ Go to top ]
- Posted by: Nathan Phelps
- Posted on: June 21 2003 22:25 EDT
- in response to William Louth
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? -
Interceptors for developers?[ Go to top ]
- Posted by: William Louth
- Posted on: June 22 2003 06:05 EDT
- in response to Nathan Phelps
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 -
Awareness[ Go to top ]
- Posted by: Bill Burke
- Posted on: June 22 2003 09:36 EDT
- in response to William Louth
> 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 -
Java JDK - Interceptors - Thoughts[ Go to top ]
- Posted by: William Louth
- Posted on: June 22 2003 11:52 EDT
- in response to Bill Burke
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 -
JSR 149 Work Area Service[ Go to top ]
- Posted by: William Louth
- Posted on: June 22 2003 13:12 EDT
- in response to William Louth
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 -
Java JDK - Interceptors - Thoughts[ Go to top ]
- Posted by: Bill Burke
- Posted on: June 22 2003 22:52 EDT
- in response to William Louth
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).
>
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 -
June Scientific American[ Go to top ]
- Posted by: William Louth
- Posted on: June 23 2003 07:35 EDT
- in response to Bill Burke
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 -
bloating the standard too early, too often[ Go to top ]
- Posted by: Logan King
- Posted on: June 20 2003 17:39 EDT
- in response to Philipp Oser
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. -
bloating the standard too early, too often[ Go to top ]
- Posted by: John Lewicki
- Posted on: June 23 2003 14:10 EDT
- in response to Logan King
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 -
What an outright stupid idea!!![ Go to top ]
- Posted by: Karl Banke
- Posted on: June 22 2003 06:45 EDT
- in response to Philipp Oser
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 :-). -
RE: What an outright stupid idea!!![ Go to top ]
- Posted by: Philipp Oser
- Posted on: June 22 2003 16:09 EDT
- in response to Karl Banke
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. -
Why did it take that long...?[ Go to top ]
- Posted by: hanspeter uebelbacher
- Posted on: June 22 2003 10:35 EDT
- in response to Philipp Oser
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 -
Should it be J2EE or Java ?[ Go to top ]
- Posted by: Dhananjay Nene
- Posted on: June 22 2003 23:48 EDT
- in response to Philipp Oser
J2EE is a powerful platform. However, we believe that there is one feature missing: the support for ORB interceptors.
[... 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. -
RE: Should it be J2EE or Java ?[ Go to top ]
- Posted by: Philipp Oser
- Posted on: June 23 2003 06:02 EDT
- in response to Dhananjay Nene
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 -
Java RMI (JRMP) Interceptors[ Go to top ]
- Posted by: riviere guillaume
- Posted on: June 23 2003 04:18 EDT
- in response to Philipp Oser
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[ Go to top ]
- Posted by: alain hsiung
- Posted on: June 25 2003 18:06 EDT
- in response to Philipp Oser
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 -
RE: we implemented EJB interceptors[ Go to top ]
- Posted by: Philipp Oser
- Posted on: June 30 2003 07:54 EDT
- in response to 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.