Article: Dynamic Routing Using Spring and AOP

by Floyd Marinescu on Jun 27, 2007 |
In this latest article, Vigil Bose shows how a business transaction can trigger business events dynamically for subsystem processing. The examples shown in this article uses Spring framework 2.0 and Spring AOP effectively to decouple the business service from the subsystem processing functionality.

Read Dynamic Routing Using Spring framework and AOP.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

XML sample not showing correctly by Alef Arendsen

Hi,

the XML sample code is not showing correctly.

Re: XML sample not showing correctly by William Louth

It always surprises me to see how much code people actually place within the AOP advice creating an architectural dependency on AOP that makes it impossible to reuse in another context such as an explicit programmatic interface. I personally prefer to use AOP (or interceptors) as bridges or adaptors from one domain/layer/tier to another domain/layer/tier. I normally start with creating the underlying system divorced of AOP concerns and then add AOP into the mix to alleviate the coding effort and simplifying the programming model for typical extension use cases. I always ensure that it is possible to use an particular feature without the presence of a particular framework or instrumentation runtime.

regards,

William

Re: XML sample not showing correctly by Vigil Bose

Hi Alef,
We fixed the XML sample code as far as I could see. You know how things get messier when it gets to convert XML tags into HTML. Thanks Alef for posting the article in your blog about using Hibernate Session API directly in the data access code.
Regards
Vigil

Re: XML sample not showing correctly by Vigil Bose

Hi William,

You could also apply the classic decorator pattern implementation to add custom behavior before and after the actual business service method invocation without using AOP in the examples shown in the article. AOP is more powerful and has got a variety of advices you can choose from, depending upon the need. The framework offers the choice and you have the freedom to make an informed decision as to which option best suits your particular use case or scenario.

Regards,
Vigil

Re: XML sample not showing correctly by Cristian Herling

William, a business logic concern should be coded as an advice when it is or becomes a cross-cutting concern. The example showed the notification module being used only in one instance (when the doRegister method gets called). If the notification module would have been used in a lot more places then you would have had a cross-cutting concern, of a business logic nature, which should have been implemented using AOP.
I agree with you saying that the component doing the work of the advice should actually reside outside of the advice, this way this component can be used outside AOP. I think AOP should be used mostly for binding a component to another component transparently.

Re: XML sample not showing correctly by Alef Arendsen

Yeah, it sounds familiar. I just revamped my personal blog a little bit and have plenty of XML fragments there as well. Sometimes I think we should never have invented the pointy brackets--would have saved us a lot of trouble ;-).

The architectural problem: What is the best use of AOP? by samuele pretini

I'have read with interesting this article, and also the post comment. So a question is come into my brain, relatively AOP.

So, during my studies I had always read that AOP is usefull when is necessary to model a cross-concern, to alleviate (as say William Louth), and evitate to write some boilerplate code in all the class that we intended to proxy. Example of this concept is the logging problem or the exception managing problem. But really I had read wath sustain Vigil Bose: the potential of AOP is significant, and it potential is not be relegate only to managing of logging, exception, etc..but it must be used also in al the situation to improve the quality of the software, regarding the readability, elegance, and obviously to separate the concerns.

William say also that is important first to write the code without the AOP advice action in field, and than apply this action of the code already working, to apply other functionality.

So in conclusion, is better for you, write (or thinking) the code from start with or without the help of AOP concept?

Thank at all.

Samuele Pretini

Re: The architectural problem: What is the best use of AOP? by Jason Carreira

I think in cases where you've had previous experience to guide you, it's fine to design and build with AOP in mind from the beginning. I wouldn't put all of the transaction handling code in every service method just to then refactor it and use the @Transactional annotation with an AOP interceptor to manage transactions. I know I'm going to need those across my app, and I use them from the beginning. I agree that pre-mature refactoring is problematic, but if you've built these systems before and seen these needs, you know some of the common things you're going to end up with, so just skip the intermediate steps.

Spring ApplicationEvents instead? by M. DeFazio

Instead of trying to write all of the Event infrastructure and AOP stuff, use Spring's ApplicationEvents... (extend ApplicationEvent) then just wire up the Router/Dispatcher as an "extend ApplicationListener" to dispatch the events to one or more subsystems. You'll have a lot less infrastructure code, and also get rid of the AOP configuration mess.

Re: Spring ApplicationEvents instead? by Jason Carreira

Spring's ApplicationEvent infrastructure is woefully inefficient, last I looked. Basically every event is passed to every listener to decide if it should handle it, and there's no good way to filter them down, register for only certain types, or make event listeners run asynchronously. I rewrote the event system for an app at my last job (where I was unfortunately unable to convince them to open source the code) to allow for registering for particular sub-classes of events and run event handlers asynchronously up to and including transaction synchronization so that event listeners would only be queued up to process if the transaction committed. I may re-write that stuff, because a central event system is an important thing, and Spring's was just not good enough for real use.

Of course, maybe they've fixed all of this stuff?

Re: Spring ApplicationEvents instead? by M. DeFazio

Jason...

to your comments:

  • Basically every event is passed to every listener to decide if it should handle it

    True, I'd suggest having a single "EventDispatcher" bean as an app listener that can filter/dispatch events to the appropriate places...

  • make event listeners run asynchronously...

    Spring 2.0 allows the SimpleApplicationEventMulticaster to pass in a TaskExecutor (i.e. AsynchTaskExecutor to run things asynchronously... then you wont be blocking on each execution)

    ...I agree that a centralized event system is a big value add in an app(Especially for trying to hook things up to support "operations"). Currently we are using the existing Spring Event infrastructure for cache refreshing, additional exception support (providing discrete "files" for critical app exceptions) and some other tooling, I've been impressed and it's worked exceptionally thus far.

    It'd be cool if we had a good, standard way of doing this...

Re: The architectural problem: What is the best use of AOP? by William Louth

AspectJ (or AOP) is a tactical implementation decision and not a necessarily a design one that needs to be absolute. We have had containers for years providing transaction management without the use of AOP or AspectJ. Where there has been interception it has been merely to route it to an actual transaction manager service component.

I did not advocate placing the transaction management code in every service method just like EJB does not force you to do this today. But if you wanted too you could still do it.

CH' post above did a much better job at explaining my viewpoint.
"AOP should be used mostly for binding a component to another component transparently."

And it should not be all or nothing at least for most systems and applications.

JSF Hibernate developer by Hiren Sheth

Hi can u please send me the code of only how the jtaTransaction work in Spring2.0.
i have two databases one is remote and another one is local.i want complete applicationContext.xml file

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy