Spring + DWR namespaces + AOP

Jump to Comments

This post topic has been updated, please read Spring + DWR namespaces + NO AOP

I have been writing this blog post for about two weeks now, writing, rewriting, deleting, changing, and opening a new blog account and starting the cycle allllll over again. But enough is enough, I have the perfect first post, I have sample code, and I am ready, I think.

I’m a big fan of rich internet applications, I don’t know many people who aren’t to be honest, the ability to turn a dull static website into a more intuitive experience is fantastic to say the least. Rich internet applications (or RIA as its often refereed to as) is like clothing as it can come in many shapes and sizes and colours, for example, you have a plethora of ajax frameworks and toolkits ranging from the aesthetic (YUI) to server services enabling (DWR). Flex and Flash also get their own mention for their highly interactive application magic which they weave, while still being able to talk to a variety of server side services with a minimum of fuss.

Now, I am not a web developer and things like xhtml, css, and ajax frameworks, like yui, are not my speciality, but frameworks which plug into the backend and expose services and apis via all manner of means, remoting or ajax, are my cup of tea.

DWR, or Direct Web Remoting, is described by the makers Getahead, or Joe Walker as:

DWR allows Javascript in a browser to interact with Java on a server and helps you manipulate web pages with the results.

DWR is Easy Ajax for Java

Its a great framework, allowing for Java classes to be easily exposed without having to code javascript files and what not, a seemless integration, to a certain degree.

The normal DWR set up requires using the DWR servlet and config xml files, a sort of custom dependency injection, although not entirely. Some frameworks, web (struts) and just plain frameworks (guice), have built their own integration for various uses, and many DWR built integrations exist, including, but not limited to, JSF, Hibernate and Spring MVC.

The DWR 1.0 way required a DWR servlet and Spring DispatcherServlet, dwr.xml config file, your usual Spring application contexts, and some simple linkings which reside in the dwr.xml file. In fact, upon reflection, I like this way a lot as the separation of remoting and application set up is simple and well defined. The DWR 2.0 way on the other hand, which is the first way I tried DWR, involves using namespaces along with a few Spring like definitions. Very clean, simple and well integrated, and my preferable option (although the more I think about the separation the more I like it, but enough about that for now).

But I do have a problem with the recommended way.

I have read many articles and blogs about the namespace set up option. I recommend you have a read through some of the following:

• Spring Integration – Getahead
• Integrating DWR and Spring
• DWR 3.0 and Spring quick preview
• Spring, DWR and Ajax made easy

All of these articles are good but they still left some questions unanswered. For example, do I need to place <dwr:remote /> tags in bean definitions of all the services and apis I want to share? Is there another way to tell DWR what beans I want to share without having to pollute my bean definitions?

The simple answer is yes and yes, the trouble was that all articles and blogs were making it look like the answers were yes and no.

I should explain why I don’t want to pollute my bean code with the <dwr:remote /> tags. Two simple reasons:

1. first, after configuring a complex service or application api bean, having extra code which should not concern the bean is unnecessary and unneeded. There should be a clear separation of concerns between bean setup and remoting, something which is not promoted by the standard documentation.
2. Second, if you are using maven or following standard practice and separating your application contexts into concerns, eg. domain, service, repositories, data etc., then adding this extra might not be possible (as the project might be multi-modular) and not wanted (separation of concerns). Especially in enterprise applications, this sort of code addition would be best implemented in such a way which allows for the service beans definitions to be left intact.

How do you do this? (took me long enough to get here)

Spring AOP Proxys.

For example, say you have a service interface (this is very important, if you want to proxy then having an interface is vital), SimpleService and its implementing class SimpleServiceImpl, then your Spring AOP config code might look like this:

(applicationContext-services.xml)
<bean id="simpleService" class="nz.co.curlybrackets.tutorial.newspringmvc.services.SimpleServiceImpl">
<property name="simpleRepository" ref="aSimpleRepository"/>
<property name="emailService" ref="anEmailService"/>
<property name="importantThing" ref="anImportantThing"/>
</bean>


(applicationContext-servletSetup.xml)
<bean id="mySimpleService" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyInterfaces" value="nz.co.curlybrackets.tutorial.services.SimpleService"/>
<property name="target" ref="simpleService"/>
<dwr:remote javascript="MySimpleAjaxService" />
</bean>

And there we are, a simple way to allow DWR to work within Spring without invading your bean definitions with extra unneeded code. This means, as you can see from the file names, that the service bean and DWR definition can be in different files allowing for a clean separation of concerns (I need to stop saying that).

DWR also has annotation support, and further ways to integrate ajax mappings to your service classes, but I think I have written enough for today.

I do have a few other issues with DWR, mainly how to link mappings to the controller, and how it integrates into Spring, but i’ll leave that for another post as well.

And before I go, I would like to say quickly, I am a fan of DWR, just because my posting isn’t praising it doesn’t mean I do not like it, it just means that I like it enough to see some of the issues with it.

Thanks

Josh

---

Possibly related posts: (automatically generated)

• Spring configuration of DWR.

5 Comments

Filed under Ajax Integration

Tags: ajax, aop, dwr, java, spring