USING AOP IN THE SAMPLE APPLICATION S PRESENTATION AND CLIENT TIERS in Font

Generator ECC200 in Font USING AOP IN THE SAMPLE APPLICATION S PRESENTATION AND CLIENT TIERS

32 try { 33 Thread.sleep(1000); 34 result = proceed ( 35 customerId,type,description, 36 balance,creditLine,beginBalance,beginBalanceTimeStamp); 37 } catch (InterruptedException ex2) { 38 ex2.printStackTrace(); 39 } 40 } 41 return result; 42 } 43 } The advice code of the aspect in Listing 12-7 is linked to the retry pointcut, which denotes the calls to the implementations of the remote Bank interface (line 16). The initial call of the service is done through the first call to proceed (line 29). If an error occurs, the retried call is done through a second call to proceed (line 34) after having waited one second (line 33). This aspect code can fall into an infinite loop when the communication layer systematically throws a RemoteException. This problem must be handled by modifying the implementation or by defining a new advice code to detect and break the infinite loops in a generic way. To apply this aspect to a set of methods, instead of one particular method, we can use the nontyped generic AOP, which uses wildcards and the joinpoint API to access the base level information reflectively. Thus, the solution presented in Listing 12-8 is applied to all the facade s methods. Listing 12-8. Applying the Retry Aspect to All Bank Methods Object around(): call(public * Bank+.*(..)) && within(Simple) { Object result=null; try { result = proceed(); } catch (RemoteException ex) { try { Thread.sleep(1000); result = proceed(); } catch (InterruptedException ex2) { ex2.printStackTrace(); } } return result; }

Some AOP technologies allow advice codes and pointcuts to be statically typed; this is called typed AOP. The Prose project, for example, allows for the typing of certain advice parameters, which results in optimization possibilities. Rickard Oberg proposes an implementation technique, based on abstract schemas, that provides static typing. AspectJ is certainly the most advanced language for this issue. In particular, it permits the binding of the different elements composing a joinpoint to some pointcut variables that can be used within the advice implementations. When AOP is nontyped, or generic, and when joinpoint information needs to be accessed, the best alternative is to use reflection. Advice codes can introspect a joinpoint and access the current object (this or target), the currently invoked or executed method, and its parameters. All this information is available through untyped objects (java.lang.Object or java.lang.reflect.Method). Programmers then manually cast and unbox the objects as needed. In typed AOP, the program can pass an int parameter to an advice code, whereas in the generic case, the same parameter will be an Object to be cast into an Integer instance. Both techniques have their advantages and drawbacks. Typed AOP permits a certain degree of program validation during the compilation and weaving phases. As a consequence, the IDE can potentially offer better support in terms of code completion, contextual help, and browsing. On the other hand, typed AOP is less flexible and makes it more difficult to write reusable advice code, as previously shown in the retry aspect. Typed AOP implies a strong dependency between the base program and the aspects. If the base program interface changes, it is likely to have an impact on the aspect s implementation, including the advice code, which can prevent reusability and evolution. This is the separation of concerns paradox: the better the concerns are separated, the less likely they are to evolve separately. Conversely, generic AOP allows the creation of generic and reusable aspects. However, it almost completely disables the compile- and weaving-time tests. Consequently, programmers should be more careful when programming with generic AOP. With regard to performance, typed AOP has a great advantage over generic AOP, especially when advice code uses the advised method parameters. Indeed, the reflexive access to the arguments implies the creation of an array of objects, which is the primary reason for performance loss in generic AOP and, more generally, in reflective programming (see the java.lang.reflect API). We should note that this performance issue is completely insignificant for most real-world applications, where the complexity of the aspects and the business layer make the overhead insignificant in comparison. For instance, the generic retry aspect presented earlier creates an insignificant overhead in comparison to the remote call, which is done to invoke the facade s service. For an optimal aspect-oriented design, both typed and generic AOP techniques should be used in a judicious way, so that the advantages of each can be realized when possible.