Elegant solution to your Non-blocking Auditing requirement
Non-blocking Auditing is an old topic in our projects. We have seen a lot of custom solutions from custom java classes, thread dispatching to whole frameworks.
Recently, we’ve been asked to migrate an old framework to the new TIBCO BusinessWorks 6. We wanted to review the different alternatives, and after a good brainstorming session, we came up with a very simple and easy solution, just tweaking a little bit the logging framework.
TIBCO BusinessWorks 6 comes with a fresh logging framework, based on logback. In our opinion, using community libraries it is a very interesting step forward, instead of holding tight the old custom ones. Community libraries come with lots of extra features like documentation, samples and extra community development that helps building more complex solutions in less amount of time. From our opinion, including logback into TIBCO Business Works 6, is a real example of that.
The cool aspect of this logging approach is, that to get it working, you just need to:
- Specify the logback AsyncAppender: there is no need to create new threads in code for async logging.
- Define the sink: you can send your logging events to a wide number of sinks. In our example, JMSQueue or JMSTopic.
And voilá! Without a single line of code, you could be sending asynchronously logging events to a JMSQueue, so those events could be consumed by other applications to filter, store, search them, etc.
At this point, you may be thinking on the potential of that solution. Why not to send the logging events to MongoDB, or through Apache Kafka (Big Data solutions)? Well, you only need to write a logback appender, and it will do the trick.
Of course, the JMS Body is an object, but that can be quickly solved too with very simple code.
And that’s all.
Well…no. Remember that TIBCO BusinessWorks 6 is OSGi based, so don’t forget to add your bundle dependencies in the logback MANIFEST.MF, otherwise a nice ClassNotFoundException will appear in your console at start up.