Five habits of highly profitable software developers for those who might think writing code can be career limiting
Or are we doing something wrong?
Aspect Oriented Programming for me always has been something that is theoretically beautiful but in practice unfeasible to apply: A good idea that buried itself by bad examples and complex implementations. Until Google pointed me to this great article about AspectJ5 and its integration into the Spring Framework. Actually I was looking for some EJB3 related Spring material but I ended up reading probably one of the first articles that after finishing left me with a �yep, I really want to do AOP, even at home’-kind of feelings.
The whole idea is actually super simple. AspectJ has been extended with two very handy mechanisms: a run time (actually load time) weaving engine and support for aspects that are expressed in Java 5 annotations. Using AspectJ’s API we do not have to rely on a separate compiler but the process of aspect weaving can be initiated whenever we like. And that is exactly the trick Spring is using. Aspects are actually Spring managed instantiations that influence other spring managed beans. When Spring is loading bean classes, cross cutting aspects are weaved in like a breeze.So, I grabbed the latest Spring release (2.0), read some more background information and started right away. Within minutes an AspectJ based interception of a completely meaningless but spring managed hello world bean was up and running. Cool! Hello world never has been so enlighting. To make things a bit more practical, I tried to implement a typical architectural constraint like “Methods on classes belonging to the an applications data access layer may only be called through methods of classes belong to the service layer.”. Normally this constraint is written down by software designers in a plain ms-word or odf ‘thou shall not’-document, but using Spring AOP it can be expressed in a bit of xml (yep, Spring ….) and a Java class. ( I am not going to argue the semantic practicalities and implications of this constraint, for me it is just an example to express the �aha feeling’.) Okay, here are some interesting pieces of the class I wrote. Full details can be found in this posts attachment (acsa.zip). @Aspect public class SystemLayeringAspect { // ……define the pointcuts to identify different layers @Pointcut(”within(com.logicacmg..*.service.*)”) public void inServiceLayer() { }@Pointcut(”within(com.logicacmg..*.dao.*)”) public void inDataLayer() { }
add some thread local sugar for administrative purpose private static ThreadLocal tlServiceCount = new ThreadLocal() { protected Integer initialValue() { return 0; }
};
define the advice to register the usage of service method calls@Around(”inServiceLayer()”)public Object serviceUsage(ProceedingJoinPoint thisJoinPoint) throws Throwable {
tlServiceCount.set(tlServiceCount.get() + 1);
Object result = thisJoinPoint.proceed();
tlServiceCount.set(tlServiceCount.get() - 1);
return result;
}
and define the advice how to deal with data access calls @Before(”inDataLayer() && this(dao)”)public void dataUsage(Object dao) throws Throwable {
if (tlServiceCount.get() == 0) {
throw new ArchitecturalConstraintFailed(dao + ” can not be accessed directly”);
}
}
Note, the difference in the advice types. The service advice needs to work around the actual method call, the dao advice does its job only upfront.That’s it. simply plug it into your Spring application context after the and off you go. ApplicationContext context = new ClassPathXmlApplicationContext(”application-context.xml”);
ExampleService service = (ExampleService) context.getBean(”helloService”);ExampleHelper helper = (ExampleHelper) context.getBean(”helloHelper”);
ExampleService service = (ExampleService) context.getBean(”helloService”);
ExampleHelper helper = (ExampleHelper) context.getBean(”helloHelper”);
service.doSomething();
try { helper.helpABit();
} catch (ArchitecturalConstraintFailed afailed) {
System.out.println(”yep catched ” + afailed);
}
In the example used to test the architectural constraint, a dao is called through a helper bean. Calling the helper directly will result in a runtime failure, calling it through the service is no problem. Seems aspect orientation has finally been made easy. Although, one should be aware of the behaviour that aspects are honoured only by java classes that are loaded through Spring. So be careful with the new operator. But besides that, all I can advice is to have fun and make good use of it.
On August 23, the Energy and Utilities EAI/Java Competence Center will organise another interesting compentence meeting.
This (LogicaCMG internal) meeting will focus on SOA (Service Oriented Architecture) and BPM (Business Proces Management).
During this meeting TIBCO will present their vision on SOA and BPM and a link will be made with their reference implementation.
Of course, collegues from other LogicaCMG businesses are very welcome but be so kind to send a notification by e-mail to Marliese Burggraaf beforehand.
Date:
August 23 (wednesday)
Location:
LogicaCMG Rotterdam
Workshop 1.3
Building Beuk
Programme:
17:30 uur - Reception and meal
18:30 uur - Welcome
18:35 uur - LogicaCMG TIBCO competence centre
18:50 uur - SOA and BPM (TIBCO)
20:30 uur - The end -> Drinks
