Don't repeat the Spring beans! (in Apache Camel and OSGi environment)

The 'Don't repeat the DAO!' article is a fundamental one for all Spring/ORM/Java world. The generic DAO pattern works well and is widely used in both commercial projects and open-source implementations.

But what if you only need one class for all of your DAOs? In one of my projects I just needed to put all records from a database view to a file. I decided not to use an ORM, but just Spring's JdbcTemplate, configured by view name and column to use in ORDER BY section. So I started to write Spring XML wiring and realized.... that I'm repeating the Spring beans! Every declaration looked something like:

<bean id="customerDAO" class="pl.touk.blog.GenericDao">
     <property name="table" value="V_CUSTOMERS"/>
     <property name="orderColumn" value="CUST_ID"/>
  </bean>

  <bean id="contractDAO" class="pl.touk.blog.GenericDao">
     <property name="table" value="V_CONTRACTS"/>
     <property name="orderColumn" value="CONTRACT_ID"/>
  </bean>
...

There were about 15 twin beans in my Spring XML files! That looked really ugly...

Virtual ESB - application integration made painless with Apache Camel

Inspired by great talk by Stefan Tilkov, we recently debated at TouK about concept of virtual ESB. The idea is to accept the fact that integration of many applications ends with some kind of spaghetti architecture. Even when you provide an ESB layer, which pretends to be a box with clear in and out dependencies, when you look inside it, you will see the same spaghetti as before.
The virtual ESB is then a set of common practices and conventions to integrate systems together, at an application level, even with no bus between.

OK, so you try to convince your application developers to implement some webservice-based integration with another application. And what's their response? 'Why to do that? We have now to generate some classes by our JAXB tools, made complex mappings to our domain classes, handle all that faults, etc. What about debugging, all that messy and unreadable XML messages, you cannot just set a breakpoint and evaluate some expression by our IDE...'

The suggestion of Stefan is to use REST instead of WS-* for integration. It's not always possible in a real world, so our answer is to switch from complex JAX-WS frameworks such as CXF to a lightweight, but powerful integration framework - Apache Camel. To avoid code generation and JAXB mappings and return to pure XML, which have great processing features. To use templating frameworks to generate XML responses. And to write mocks and unit tests, just like you do for your DAO and service layers.

Event processing in camel-drools

In a previous post about camel-drools I've introduced camel-drools component and implemented some simple task-oriented process using rules inside Camel route. Today I'll show how to extend this example by adding event processing.

So how to describe an event? Each event occur at some time and lasts for some duration, events happen in some particular order. We have then a 'cloud of events' from which we want to identify those, which form some interesting correlations. And here the usage of Drools becomes reasonable - we don't have to react for each event, just describe set of rules and consequences for those interesting correlations. Drools engine will find them and fire matching rules.

Suppose our system has to monitor execution of task assigned to users. After a task is created, user has 10 days to complete it. When he doesn't - an e-mail remainder should be sent.