Good pattern or framework for adding auditing to an existing app?

Question

I have an existing J2EE enterprise application to which I need to add auditing, i.e. be able to record CRUD operations on several important domain types (Employee, AdministratorRights, etc.).

The application has a standard n-tier architecture:

• Web interface
• Business operations encapsulated within a mixture of stateless session beans and transactional POJOs (using Spring)
• persistence is a mixture of direct JDBC (from within the business layer) and EJB 2.x BMP entity beans (I know, I know)

My question is: are there any standard patterns or (better still) frameworks/libraries specifically for adding auditing as a cross-cutting concern? I know AOP can be used to implement cross-cutting concerns in general; I want to know if there's something specifically aimed at auditing.

Answer 1

Right now I'm leaning towards using Spring AOP (using the "@AspectJ" style) to advise the business operations that are exposed to the web layer.

Answer 2

Try an Aspect Oriented programming framework.

From Wikipedia "Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by allowing the separation of cross-cutting concerns".

Answer 3

This question is a partial duplicate of: http://stackoverflow.com/questions/23770/good-strategy-for-leaving-an-audit-trailchange-history-for-db-applications#23780.

Several strategies are discussed there, but they are not necessarily J2EE-specific.

Answer 4

For all EJBs you can use EJB 3.0 Interceptors (This is something similar to Servlet filter) and another similar interceptor for Spring (not familiar with spring) As you are using EJBs as well as Spring that may not cover the whole transactions. Another approach could be using a Front Controller however that requires some modification in the client side. Yet another approach could be using a Servlet Filter however that means implementing the domain logic in the presentation layer.

I would recommend the Front Controller in this case.

Answer 5

I'm going to go a bit against the grain here and suggest that you look at a lower-tier solution. We have a similar architecture in our application, and for our auditing we've gone with database-level audit triggers that track operations within the RDBMS. This can be done as fine- or coarse-grained as you like, you just have to identify the entities you'd like to track.

Now, this isn't an ideologically pure solution; it involves putting logic in the database that is arguably supposed to remain in the business tier, and I can't deny that this view has value, but in our case we have many independent application interacting with the data model, some written in C, some scripted, and others J2EE apps, and all of them have to be audited consistently.

There's possibly still some AOP work to be done here on the J2EE side, mind you; any method that updates the database at all may have to have some additional work done to tell the database which user is doing the work. We use database session variables to do this, but there are other solutions, of course.