Archive for March, 2009

Starting yet another blog…

I figured that dumping lots of dev information about axiom here was going to get on my nerves (and break the cycle of hardly ever using this blog!?) so I’ve started a new one. Just focussed on the project which is soon to go into *proper* use despite not yet reaching beta status! Fingers crossed it won’t go bang too frequently and kill all my time for other projects. 😉


Leave a comment

Testing enterprise integration scenarios

This is the first opportunity I’ve had to post for a while and sadly it’s because I’m at home feeling sick! Nonetheless, I wanted to sing the praises of my latest chunk of open source goodness. Axiom shares its name with a open source computer algebra system that’s been around for 15 or so years. Now this clash was accidental and leaves me in need of another catchy title, but the project itself is a little more original. I had in mind a twofold purpose when I started out: first and foremost, to simplify discovery and testing of heterogeneous integration scenarios. I wanted to create something that would help friends and colleagues to document, validate and continuously test (and reintegrate) the kind of complex integration architectures that we see in a large company like ours.

Axiom attempts to address these needs one by one. The first is the process of documentation and discover. Based on the Apache Camel routing and mediation engine, Axiom is connected to your stack by means of the camel routing DSL code. This comes in two dialects: Spring XML or an internal DSL based on code (more about this later). I’ve been looking at Camel on and off for a while now and have wanted to recommend it for at least two projects, but I don’t recommend technology I haven’t used and neither was an occasion for spiking. This is the second reason behind my latest undertaking. 🙂

Now this process of setting up routing rules in Camel involves identifying the various actors and resource types and giving everything a URI. These twin processes of identifying and classifying the system topology are an excellent discovery tool – I cannot count the number of times I’ve seen the light bulb go off in people’s heads whilst going through an exercise like this. Axiom routes are usually defined in a script, using a superset of the Camel Java DSL. This is made possible because Axiom embeds JRuby as a scripting engine, both for extensibility (plugins and extensions can be written ruby) and as a configuration DSL. This is in keeping with my belief that “code as configuration” it often a better choice than mountains of XML or whatever.

Axiom also follows the (rather American and I think very wholesome) mantra of “eat your own dog food.” Axiom uses the same configuration system, DSL and routing/processing APIs to handle its own control flow and that of the target system(s). This comes with my favorite advantage in software development; Keep things simple and they will work well and be easy to understand. It also means that Axiom is itself, just as configurable and manageable as any system that can be configured using Camel.

There’s obviously a lot more to say about this, but for the time being, I’ll just leave you with an example set of rules that would used to validate schema on the wire and produce compliance reports:

#!/usr/bin/env jruby

require 'axiom'
load_plugin :w3cverify, 'w3cverify.rb'

route {
  w3cverify(config >> 'bt.f1.xsd.uri').proceed

This kind of capability makes defining rules very simply and along with support for writing out HTML (and other format) reports means that you can plug your axiom based integration tests into a CI framework quite easily – at least that’s the aspiration anyway. Next post, I’ll talk a bit about how to define your own plugins (like the w3cverify plugin in this case) in JRuby and Java.