AOP

[kundan varma]

Hi All,
Have heard a lot about AOP, when to go for AOP and what are the benefits of it, can it be used with EJBS and use application server??
Please suggest.
Thanks,
kundan

[Scott Ambler]

http://www.google.ca/search?hl=en&q=aop+benefits&meta=

http://www.google.ca/search?hl=en&q=aop+ejb&meta=

- Scott

[kundan varma]

Hi Scott,
what your opinion about AOP. Do you think its better than oop??
Thanks,
kundan

[Mattias Arthursson]

It's really not a question of OOP or AOP; rather you apply AOP on your object-oriented system, adding proxies in some places and perhaps introducing code in other. AOP can be an extremely powerful tool if used correctly; however it kind of requires a different way of thinking.

BTW, if you're using EJBs at the moment you're already sort of taking advantage of some AOP features; transaction management and security is automatically applied with proxies by the EJB container. The same can be achieved using AOP with e.g. Spring; the difference being that you can decide yourself what you want to do (as opposed to the EJB container that does it whether you want to or not).

[Scott Ambler]

I think that there's some good ideas in AOP, and that some people are doing interesting things with it, but I suspect that it'll be nothing more than a niche technique. Use it if it makes sense for your situation and you are working with people who can use it effectively and maintain the code over time.

- Scott

[Peer Reynders]

Originally posted by Scott Ambler:
Use it if it makes sense for your situation and you are working with people who can use it effectively and maintain the code over time.

Not likely in most places. The "Young Punks" who are too busy struggling with OO, Patterns, Generics, the current framework/server/development tool-du-jour aren't ready to take on AOP and those who might finally "get it" take that project management position.
Then again, someone who might choose to use AOP might not have the slightest interest in any "full-time" project management position.

[Stan James]

My concern about AOP is that the code is no longer the truth. You have to read it with some understanding of how it might be modified before it runs. The tools might be good enough to overcome this concern if they show the relationship of the code and whatever AOP will change well enough.

[Mattias Arthursson]

Originally posted by Stan James:
My concern about AOP is that the code is no longer the truth.

Well, that's only partially true. It all comes down to two things: separation of concerns and croscutting concerns.

If you need transactions or security on your class that is usually nothing that has to do with the main responsibility of the class; good design tells us that it should be handled by something else, in the AOP case (or EJB world for that matter) this can be easily solved using proxies.

Code introductions can be a great tool to eliminate code duplication, one of the worst code smells. However, this easily gets very complicated without the proper tool support, but good support is provided for several popular IDEs (e.g. eclipse).

[Stan James]

Good points if we take care to do things well. Proper separation of concerns is critical and you have to trust in it if you can't see what the AOP will do. And good tools will make a lot of difference, too. I'm emotionally prepared to be swayed by AOP if and when I ever get a good excuse to dive in, just expressing the things that I'll be looking for on the way.

[kundan varma]

But if both AOP and EJB is doing the same stuff like separation of transaction and security...why not to stay with EJB ??

Thanks,
kundan

[Peer Reynders]

Originally posted by kundan varma:
But if both AOP and EJB is doing the same stuff like separation of transaction and security...why not to stay with EJB ??

One of the main drivers is testability. It was notoriously slow in EJB 2.1 and prior to test changes because of the build and deploy steps for EJB. As a result you don't test often enough and the changes between tests tended to be too big - in other words test-driven development was impossible. EJB 3.0 changes this somewhat because you can use POJOs (Plain Old Java Objects) - so at least your POJOs can be developed with test-driven development.

With AOP you can prevent the injection of the server/container dependent aspects during the development of the business logic (you may even be able to inject replacement mock-aspects - not sure though) so that you can develop and test your code outside of the server/container. The idea of course is that the server dependent aspects have much less reason to change (compared to the business logic) - and therefore only need to be tested relatively infrequently. Of course that only works if you practice proper separation of concerns.
[ March 30, 2006: Message edited by: Peer Reynders ]

[Mattias Arthursson]

Peer is quite correct. Testability is one very strong reson to use POJOs rather than EJB.

Originally posted by kundan varma:
But if both AOP and EJB is doing the same stuff like separation of transaction and security...why not to stay with EJB ??

The choice is not only decided by transaction and security support.

Another big difference is that the EJB technonogy is invasive, in that you need to implement specific interfaces, adding specific methods and behaviours that you will probably never need.

Also, they're really not doing the same stuff. What I was saying is that some of the things going on in an EJB container might be described as AOP. One big difference is that using EJBs you're stuck with doing these things the EJB way (and not only that - they become applied whether you want it or not). E.g. when it comes to security, the standard EJB seurity scheme is insufficient for all but the simplest of applications. Using POJOs and AOP
you're free to use any security implementation you feel will meet your needs (e.g. Acegi).

Bottom line: using EJB you are stuck with the stuff the EJB conatiner gives you, whether you like it or not; using AOP you can apply any (or none) proxy at any place you like.

[kundan varma]

Ya agreed but with EJB3 things have changed a lot and you can go ahead with TDD . What about distributed components??? can we achieve that easily with AOP and even AOP containers are providing some services which can or cannot be robust faithful right. So after EJB3 why would we prefer AOP. Also we can go with Hibernate and JDO with spring or any IOC container. But i guess we cannot call IOC containers as AOP .

Thanks,
kundan

[Mattias Arthursson]

Originally posted by kundan varma:
Ya agreed but with EJB3 things have changed a lot and you can go ahead with TDD .

Well, EJB3 changes some things, but that is not to say that the EJB container becones a real IoC container. The IoC support is limited, so using TDD will not be as easy as when developing using POJOs.

Originally posted by kundan varma:

What about distributed components??? can we achieve that easily with AOP and even AOP containers are providing some services which can or cannot be robust faithful right.

Fowler's first rule of distribution: Do not distribute. You very rarely benefit from distributing your components. If you need to share some things between servers in a cluster, use a distributed cache instead.

Originally posted by kundan varma:

So after EJB3 why would we prefer AOP.

It's really not the same thing. IMHO a lightweight container with AOP support offers you far greater flexibility than an EJB container.

Originally posted by kundan varma:

Also we can go with Hibernate and JDO with spring or any IOC container. But i guess we cannot call IOC containers as AOP .

Hibernate or JDO together with Spring would be sufficient for most any requirement you can think of. All IoC containers do not provide AOP support; however the Spring framework does.

[Peer Reynders]

Originally posted by Mattias Arthursson:
Fowler's first rule of distribution: Do not distribute. You very rarely benefit from distributing your components.

(Going off on a tangent - again):
Hence the growing interest in SOA (Services Oriented Architecture). First everybody proclaimed that OO would increase reuse. Then the scale got turned up a notch and the buzz was all about components. While reusing components in different applications is a good thing, reusing the same component remotely from different applications didn't turn out so well - but J2EE is basically a distributed component architecture. So once again the scale was turned up a notch and "they" started thinking "services". This has been brewing for a while - the emerging Web Service technologies simply poured gasoline on the fire (i.e. in many cases SOA can be accomplished with more restrictive but efficient interfacing technologies).

Now you can decide, on a service by service basis, whether the whole J2EE stack is actually necessary or whether a Spring+(Hibernate||JDO) setup is more appropriate. And should it become necessary, a Spring+(Hibernate||JDO) solution can be deployed within a container anyway.

[Remco Bos]

i.e. in many cases SOA can be accomplished with more restrictive but efficient interfacing technologies

Yes it's off topic, but maybe we can start another thread for this one because I really want to hear your opinion about those "more restrictive but efficient interfacing technologies". I also believe that's the way to go..