Discussions

News: Book Review: Spring 2.5 Aspect Oriented Programming

  1. Table Of Contents http://www.packtpub.com/article/aspect-oriented-programming-with-spring-2-5-table-of-contents 1. Understanding AOP Concepts 2. Spring AOP Components 3. Spring AOP Proxies 4. AspectJ Support 5. Design with AOP (Downloadable for free!! - http://www.packtpub.com/files/spring-2-5-aspect-oriented-programming-sample-chapter-5-design-with-aop.pdf) 6. Three-tier Spring Application, Domain-Driven Design 7. Three-tier Spring Application, Tests and AOP 8. Develop with AOP Tools Tag Line: Create dynamic, feature-rich, and robust enterprise applications using the Spring framework. The best part of this book is it gives you upfront a list of what you require for development and the authors use a stable version of Spring 2.5.6 unlike other books in the market which use the snapshot release. Also, the entire open source development environment is announced before you get into the chapters :-) Chapter 1: Understanding AOP Concepts It starts of with introduction of AOP concepts within the Spring IOC container. There is a clear explanation on the limits of object-oriented programming (Code scattering, code tangling) which can cause the system to have duplicate code and functionality not being clear and how AOP overcomes them by modularizing, decoupling and using aspects. The explanation is very nicely represented with diagrams. I like the fact that it teaches you what you mean by an aspect before getting into the details of how and where they act and the Spring support in programmatic way using annotations and by XML configuration (before advice, after returning advice, around advice, after throwing advice). The simple "small but complete" code examples go with it very well. Most other books I have read just had snippets of code, which was annoying to test. I had to write everything in the chapter to get it to work. I would have liked a better formatting to the code examples though. It is difficult to tell between text if not for the font. It goes on to explain the aim of Spring AOP, which is to allow the realization of JEE functionality in the simplest manner and without being intrusive. There are code samples of Programmatic way to use Spring AOP(MethodBeforeAdvice, AfterReturningAdvice, MethodInterceptor, ThrowsAdvice). The same examples are used in the old Spring way ie. Spring beans declared in XML file and using ProxyFactoryBean. The same examples are then realized using the syntax of AspectJ annotations to obtain the same advice that we saw in the programmatic examples (@Before, @AfterReturning, @Around, @After, @AfterThrowing). The XML schema based configuration of the examples is also explained. Chapter 2: Spring AOP Components The chapter 2 on AOP components does a great job at introducting concepts like Aspect, Pointcut and its components, four pointcuts provided by Spring ie. 1. NameMatchMethodPointcut, 2. RegexpMethodPointcut, 3. StaticMethodMatcherPointcut, 4. DynamicMethodMatcherPointcut. This follows operation on pointcut like union, intersection and Composable Pointcut which can compose two or more pointcuts together. It also touches JoinPoint, Advice (before advice, after returning advice, after throwning advice) and Advisor. It deals with appropriate situations to use these to obtain desired results. I don't like Console window of Eclipse is used for results every time. They could have potentially used a simple text output. Introductions, which are an important concept in Spring AOP, permit us to dynamically introduce new one-object functionalities and obtain the effects of multiple inheritance in Java (mixin). Chapter 3: Spring AOP Proxies Chapter 3 helps understand the concept of Proxies which is the basic concept of Spring AOP (CGLIB-generate the bytecode for the new class on the fly for each proxy, reusing in those cases that were already created AND JDK- implement the interface that manages invocations). How to create proxy programmatically with Classic Proxy(Command Pattern) and AspectJ Proxy (@Aspect). ProxyFactoryBean, which allows us to focus our attention and development on crosscutting, concerns to apply through the proxy, rather than focus on the proxy. How to use Auto proxies with BeanNameAutoProxyCreator, DefaultAdvisorAutoProxyCreator and AbstractAdvisorAutoProxyCreator. In the later part it touches advanced concepts like advised objects and Target sources (Hot swappable target sources, pooling target sources, prototype target sources and threadlocal target sources). Chapter 4: AspectJ Support The next chapter deals with AOP with AspectJ way of defining an aspect, pointcut, joinpoint, binding and advice (@Before, @AfterReturning, @AfterThrowing, @After, @Around) and Introduction (@DeclareParents) which makes Spring even more powerful and simple. The focus is on the syntax and pointcuts are applied to complex context bindings or Spring beans. The authors go on to describe how to logically apply the pointcut designators depending on selection of methods' names, types of argument, selection on types of return, selection on declared exceptions, selection on hierarchy, selection on annotations. How to add arguments to advice methods and bind any argument value, exception, return value or annotation binding. Introductions allow declaring that a target object implements interfaces, providing the implementation. Advisors are useful for joining together the aspect and advice in classic Spring AOP. The most common use is with the advice for transactions . There are beautiful examples to show how to use AOP with the domain object to solve the concurrency of aspects and the mixin of configurations: Dependency injection in domain objects @Configurable() and AnnotationBeanConfigurerAspect Advice ordering @Order(value) Configuration mixin XML or Annotation Aspect instantiation model AspectJ's perthis and pertarget instantiation models To enable the complete AspectJ framework in Spring AspectJ's load time weaving with Spring is required. This is done through aop.xml in META-INF directory in the classpath root. Spring support for LTW can be as easy as in the config file. AspectJ's LTW agent can be invoked by adding a VM argument to the command line. AOP strategy considerations has a good argument about: · Spring AOP proxy · Spring with AspectJ Weaver · AspectJ Chapter 5: Design with AOP Chapter 5 gets into the design aspect touching hard to understand concepts like concurrency, caching and security (authentication and authorization) which are not well touched in other book available. How Spring can obtain a cleaner and concide source which is easy to maintain and debug is highlighted. Concurreny is explained with ReadWriteLock and Transparent caching which helps in terms of speed and resources is explained with an example of ehcache. Spring sercurity covers AccessDecisionManager (AffirmativeBased, ConsensusBased, UnanimousBased) and AccessDecisionVoter This is applied to code in the following instances: · Securing methods with security interceptors · Securing methods with pointcuts · Securing methods with annotations Chapter 6: Three-tier Spring Application, Domain-Driven Design Three-tier Spring Application, Domain-Driven Design is a case study and explains capabilities and features of DDD. The topics covered are DDD, Domain layer and Infrastructure layer. The roles and responsibilities of objects with DDD are classified into following categories: · Entities · Aggregates · Modules · Value Objects · Factories · Repositories · Services A conceptual architecture is seen from the following standpoints: · User Interface · Application Layer · Domain Layer · Infrastructure Layer A sample application (online wholesale fresh-fruit shop) is then used to describe concepts like Design where interfaces are defined and implemented with @Configurable Services intrinsically activities or actions, which explain relationship with other objects, Factories used to create domain objects before the user interaction with application layer. Caching is used here. @Component Repositories, which deal with persistence and used by domain classes. @Repository. iBATIS is used for persistence. Hibernate would be nicer. Chapter 7: Three-tier Spring Application, Tests and AOP Three-tier Spring Application, Tests and AOP is also case study which takes the last chapter further by defining the Application layer and user interface Controllers using the Domain Classes are shown which belong to the application layer. These interpret the GUI commands. Annotations like @Controller and @RequestMapping are used Tests Junit 4.5 with annotations is used testing this sample application. The main class is marked with @RunWith and @SuiteClasses, @BeforeClass (initializing), @AfterClass (tear down) are used in the code. JUnit executes any method annotated with @Test as a test method. Most of the testing code is geared towards testing in Eclipse IDE. AOP Spring AOP (@Configurable Annotation in conjunction with LTW jvm) and AspectJ aop.xml (LTW) are then added to the code to acheive the following: · Cache · Concurrency (@Order, @Before, @After) · TimeExecutionManagedAspect · To measure the method's average execution time (@ManagedResource, @ManagedAttribute, org.springframework.util.StopWatch, @ManagedOperation) · Transactions · All the operations executed on the database must take place in a transactional way (commit or rollback series of transactions). I use this extensively · Security Chapter 8: Develop with AOP Tool Extra points to the authors for including the setup of development environment for Spring AOP development on Canonical Ubuntu Linux 8.10, Apple MacOSX 10.5.6, or Windows XP, tools needed and where to download them. · Java Development Kit · Spring · Eclipse · Eclipse Plugins · Spring IDE · AspectJ Development Tool (AJDT) · Apache Tomcat installation and configuration for · Ubuntu Linux · MacOSX · Microsoft Windows · PostgreSQL · Ubuntu Linux · MacOSX · Microsoft Windows To summarize, I enjoyed reviewing this book. I loved the examples, diagrams and screen shots. Most of the code examples have been shown in both the annotations and XML based configuration for you to choose. Again, I reiterate the fact that the examples and simple and complete. The differences of 1.x and 2.5 version have been highlighted. Surprizingly I found a couple of links on the packtpub site pointing to US stores broken. Who can use the book: Any developer or architect who wants to learn and use the power of Spring 2.5.x and AOP (Annotations and XML). It assumes prior practical experience with Spring and configuration. You can visit http://www.packtpub.com/files/code/4022_Code.zip to directly download the example codes in the book. Paperback: 332 pages Publisher: Packt Publishing (February 27, 2009) Language: English ISBN-10: 1847194028 ISBN-13: 978-1847194022 Product Dimensions: 9.1 x 7.5 x 0.9 inches About the Author (As on the site) Massimiliano Dessì is an experienced Java developer, who started developing JEE applications in 2000. In 2004 he discovered the Spring Framework 1.0, and since then he has been one of its most enthusiastic users. He works as a Software Architect and Engineer for Sourcesense (http://www.sourcesense.com), one of the leading European Open-Source System Integrators. Before joining Sourcesense, he worked as software architect for CRS4 (http://www.crs4.it). He's also an active technical writer, author of various articles, publications, and reviews available on http://www.jugsardegna.org/vqwiki/jsp/Wiki?MassimilianoDessi and on http://www.slideshare.net/desmax74/slideshows. Massimiliano is also a frequent speaker at Users Groups conferences, including, Java Users Groups, SpringFrameworkUser Group, Javaday, and Linux Users Groups. He is one of the founders of Java User Group Sardinia (https://jugsardegna.dev.java.net/ and http://www.jugsardegna.org), the founder of "Spring Framework Italian User Group", "Jetspeed Italian User Group" and "Groovy Italian User Group". He maintains a personal weblog at: http://jroller.com/page/desmax and lives in Cagliari, Sardinia with his family. (http://www.packtpub.com/aspect-oriented-programming-with-spring-2-5/book). This is the link to my blog : http://ejvyas.blogspot.com/2009/04/review-spring-25-aspect-oriented.html

    Threaded Messages (21)

  2. You keep using that word, "Book Review". I do not think it means what you think it means.
  3. LOL I completely agree, it's more like a detailed TOC! Whe
  4. It is a style of technical book review. Please check..
  5. AOP[ Go to top ]

    AOP in general (not just Spring AOP) has failed. 'Weaving' code into half-baked applications to complete them simply is a bad idea.
  6. Re: AOP[ Go to top ]

    AOP in general (not just Spring AOP) has failed. 'Weaving' code into half-baked applications to complete them simply is a bad idea.
    I disagree. I developed some pretty clean apps using AOP. In my experience, the biggest problem is getting people to understand how to use it. It isn't for everyone,but no solution works for everyone.
  7. Re: AOP[ Go to top ]

    Man I'm really sick of people saying AOP doesn't work. AOP doesn't solve world hunger but it does help with addressing cross cutting concerns. AOP and OOP are not mutually exclusive. I have seen some filthy code scattered all over the application when a simple Aspect would've done the trick. Technology like any other tool can be abused and used incorrectly when placed into the wrong hands. So don't blame the tool when the worker can't craft good software. Now, in relation to the book unfortunately I was not too impressed with it. I had to send it back. I have read better books on Spring AOP. I have been fortunate enough to be a reviewer for the new edition of AspectJ in Action which covers a great deal on Spring AOP.
  8. Re: AOP[ Go to top ]

    AOP in general (not just Spring AOP) has failed. 'Weaving' code into half-baked applications to complete them simply is a bad idea.
    Couldn't agree more. Hype around aspect is nothing but marketing. It significance on daily programming for average developer is almost nothing.
  9. Re: AOP[ Go to top ]

    May be reading the book will expose the power of AOP
  10. Re: AOP[ Go to top ]

    AOP in general (not just Spring AOP) has failed. 'Weaving' code into half-baked applications to complete them simply is a bad idea.


    Couldn't agree more. Hype around aspect is nothing but marketing. It significance on daily programming for average developer is almost nothing.
    I *do* agree with that last statement. The "average" developer is one who is, generally speaking, the last to embrace pretty much anything useful or different. I always enjoy that anything technology that is misused, misunderstood, or simply not liked is dismissed as hype. I understood it and got it work and it paid off *real* benefits to my projects. It worked exactly as advertised. But I'm not average. Ask yourself, in what facet of your life would you want the average anything affecting your life? Average doctor? Average lover? Average mechanic? Average financial planner? Average airline pilot? Why be satisfied with the opinions of the average developer, content with mediocrity, costing your money because of his inefficient averageness, because he is happy to write off anything potentially useful as "hype?" Why have the average anything be the limiting factor? This would be a hell of a world if we depended on the average person in a given field to advance that field? Average developers have their place- do as told, bug fixes, and maintenance work, not evaluating nor design systems.
  11. Re: AOP[ Go to top ]

    AOP in general (not just Spring AOP) has failed. 'Weaving' code into half-baked applications to complete them simply is a bad idea.


    Couldn't agree more. Hype around aspect is nothing but marketing. It significance on daily programming for average developer is almost nothing.


    I *do* agree with that last statement. The "average" developer is one who is, generally speaking, the last to embrace pretty much anything useful or different.

    I always enjoy that anything technology that is misused, misunderstood, or simply not liked is dismissed as hype.

    I understood it and got it work and it paid off *real* benefits to my projects. It worked exactly as advertised.

    But I'm not average.

    Ask yourself, in what facet of your life would you want the average anything affecting your life?

    Average doctor?
    Average lover?
    Average mechanic?
    Average financial planner?
    Average airline pilot?

    Why be satisfied with the opinions of the average developer, content with mediocrity, costing your money because of his inefficient averageness, because he is happy to write off anything potentially useful as "hype?" Why have the average anything be the limiting factor? This would be a hell of a world if we depended on the average person in a given field to advance that field?

    Average developers have their place- do as told, bug fixes, and maintenance work, not evaluating nor design systems.
    +1
  12. Re: AOP[ Go to top ]

    +1 well said
  13. Re: AOP[ Go to top ]

    Average developers seem to be busy doing and figuring out stuff. I don't believe either average or above-average ones have time to flame silly!
  14. Re: AOP[ Go to top ]

    Nice post David!
    <I *do* agree with that last statement. The "average" developer is one who is, generally speaking, the last to embrace pretty much anything useful or different.
    It must be "New Math" or something like that but it seems to me that most "average" developers are below average. Not sure it is mathematically possible - but it do the math and you'll agree. :)
  15. Re: AOP[ Go to top ]

    It worked exactly as advertised. But I'm not average.
    Yep, you are special, sooo special. You certainly left behind that antique AOP stuff to the maintenance programmers for new technologies above the average.
  16. Re: AOP[ Go to top ]

    It worked exactly as advertised. But I'm not average.


    Yep, you are special, sooo special. You certainly left behind that antique AOP stuff to the maintenance programmers for new technologies above the average.
    You make no sense "casual visitor." No wonder you have problems understanding Aspect Oriented programming.
  17. Re: AOP[ Go to top ]

    It worked exactly as advertised. But I'm not average.


    Yep, you are special, sooo special. You certainly left behind that antique AOP stuff to the maintenance programmers for new technologies above the average.


    You make no sense "casual visitor." No wonder you have problems understanding Aspect Oriented programming.
    I agree David, it really does seem as though Casual visitor fails to grasp the usefulness of AOP.
  18. Re: AOP[ Go to top ]

    AOP in general (not just Spring AOP) has failed. 'Weaving' code into half-baked applications to complete them simply is a bad idea.
    IMO and experience, AOP shines when used to add behavior to annotations. Then when looking at code, you know exactly what is going on rather than having an IDE tell you the joinpoints.
  19. Chapter 5 says "With AOP we can have cleaner code, much more concise and easier to maintain and debug." Sure, when compared to code not originally written with the best tools available for the job. But what if the proper tools had been used? In the case of the example given in this chapter, such tools would be a JPA (e.g., Hibernate) or a JDO implementation for the issues of concurrency (together with the use of isolated DB transactions, naturally) and transparent caching, and perhaps EJB 3 for security. Aren't there better examples for good uses of AOP? It seems I always end up with the impression that AOP is a solution looking by a problem...
  20. Chapter 5 says

    "With AOP we can have cleaner
    code, much more concise and easier to maintain and debug."

    Sure, when compared to code not originally written with the best tools available for the job. But what if the proper tools had been used? In the case of the example given in this chapter, such tools would be a JPA (e.g., Hibernate) or a JDO implementation for the issues of concurrency (together with the use of isolated DB transactions, naturally) and transparent caching, and perhaps EJB 3 for security.

    Aren't there better examples for good uses of AOP?
    It seems I always end up with the impression that AOP is a solution looking by a problem...
    I used AOP for Security(that is sophisticated security not bound by simple user credentials,but instead was determined based on credentials, business logic, and data) Profiling Caching( Exception translating Operation retrying(trying calls to external systems that failed, but could potentially be tried again) System notifications All defined declaratively, could be applied to specific methods or packages, fully reusable across even different projects in terms of design and in some cases code. And *vastly* simpler pure business code. It is telling to me that people who've bothered to actually use it don't seem to complain. Only the people who've *read* about it.
  21. I used AOP for

    Security(that is sophisticated security not bound by simple user credentials,but instead was determined based on credentials, business logic, and data)
    Profiling
    Caching(
    Exception translating
    Operation retrying(trying calls to external systems that failed, but could potentially be tried again)
    System notifications

    All defined declaratively, could be applied to specific methods or packages, fully reusable across even different projects in terms of design and in some cases code.

    And *vastly* simpler pure business code. It is telling to me that people who've bothered to actually use it don't seem to complain.

    Only the people who've *read* about it.
    For complex URL-based security, I used Servlet Filters, and I don't think AOP would have helped. For profiling, the JVM profiler (-Xprof) was enough. For caching, the Hibernate second-level cache with EhCache solved the problem. For the other items you mention, in particular exception translating, I would be interested in more info. Could you give an example of how AOP could be used to reduce exception handling code? Don't get me wrong, I believe there are valid uses for AOP; I just have not found one yet for the projects I developed. Well, actually, I would like to use "subclass introduction" in persistent entities, but AFAIK neither AspectJ 5 nor JBoss AOP 2.5 support this (only interface introduction).
  22. I used AOP for

    Security(that is sophisticated security not bound by simple user credentials,but instead was determined based on credentials, business logic, and data)
    Profiling
    Caching(
    Exception translating
    Operation retrying(trying calls to external systems that failed, but could potentially be tried again)
    System notifications

    All defined declaratively, could be applied to specific methods or packages, fully reusable across even different projects in terms of design and in some cases code.

    And *vastly* simpler pure business code. It is telling to me that people who've bothered to actually use it don't seem to complain.

    Only the people who've *read* about it.


    For complex URL-based security, I used Servlet Filters, and I don't think AOP would have helped. For profiling, the JVM profiler (-Xprof) was enough. For caching, the Hibernate second-level cache with EhCache solved the problem. For the other items you mention, in particular exception translating, I would be interested in more info. Could you give an example of how AOP could be used to reduce exception handling code?

    Don't get me wrong, I believe there are valid uses for AOP; I just have not found one yet for the projects I developed.

    Well, actually, I would like to use "subclass introduction" in persistent entities, but AFAIK neither AspectJ 5 nor JBoss AOP 2.5 support this (only interface introduction).
    See, This is my point. The issue is not in the tool. First, that servlet filter works on in web apps. And what if your security has aspects(no pun) other than being just page-based. With AOP, my solution worked both inside and outside the web-container. Second, caching is not just a hibernate problem. I mean, they didn't invent the need for it. What if you have something that requires a complex calculation, a memoizer? What if you are integrating with an external systems that are simply slow? Or loses its connection? Again, caching applied via AOP can handle all this easily and is reusable. And you can applied declaratively. For profiling, it took me all of an hour to put in place code to gather some useful statistics without bring the JVM into the equation, that could give me useful information for a variety of interfaces up and down my code-middle tier, security modules, external systems modules, data access. One hour of work and now anything I wrote could benefit from it. And I control the look and feel of the data. I worked with a couple of systems that had interesting ideas about return error codes, throwing checked exceptions that usually were misleading and also had to deal with a legacy library that dealt with the legacy systems API. I introduced code via AOP that translated that stuff into more standardized, more(hopefully) descriptive exceptions without screwing up the legacy code. It also worked in conjunction with a RetryThrowsAdvice that upon receiving certain classes of exceptions would handle system recovery attempts. All of this without messing with the existing code and can be applied to methods in a variety of ways- by package, method name, etc... My point? Could you do this without AOP? Sure, we all did it for years. But what I noticed that was my business code became much cleaner without that stuff in the way. And my refactoring those crosscutting items out, I ended up with more reusable code. If someone needs to change the business logic, they didn't have to read through code that was really unrelated to the business logic. Why should the business logic be concerned with how any of that stuff is handled? I'm not the type of person who tries for the sake of trying. I need to see intrinsic value before moving to the coding stage and the Dynamic Proxy then AOP seemed like it could solve a class of problems, namely, what do do with behavior that doesn't really obey the object hierarchy, but is part of it, is used by it. How could I reduce the business logic code to just that? To me, if you find servlet filters useful, AOP would be a natural progression. I tend to use servlet filters as a starting point to explain AOP.