I’ve pretty much finalised the design of GADfly, with a Windows service using a durable consumer to pull messages from a dedicated topic provided by Apache ActiveMQ inside Apache Camel. Just needed to try it out for real, so I knocked up FlyTrap, a small Windows GUI app to send messages to a test topic and consume them, using the GADfly functionality to create and delete accounts and directories in ActiveDirectory.

It’s a very simple app that tells you how long it took to create and delete the accounts and directories, including the messaging time:

JISC have come up with a competition to make use of the MOSAIC data that summarises library lending in gigantic XML files, so I thought I’d put the old grey matter to work in my spare time and the result is iLib. It’s a simple application built on Passenger + Rack + Sinatra, and is 100% Ruby and open source. The MOSAIC XML files are quite difficult to deal with as they’re around 200Mb each which precludes DOM handling and SAX on every request is a no-goer. So I built a processing pipeline that converts the MOSAIC XML to native iLib JSON objects. As the XML is essentially static, for the moment anyway, it made sense to run the converter as a cron job once a night to update the JSON and build the UI to work directly with the JSON. It’s fast, lean and pretty darn mean, even if I say so myself! The stack is summarised below:

I use XMLBeans extensively in Java so I don’t have to work with raw XML, especially SAX, as it’s a real pain to deal with. XMLBeans, given an XSD and xsdconfig will create a load of Java classes that map directly to the XML documents. All very nice but what about C#? When I was doing the C++ version of GADfly I was back into raw XML but there is something quite nice you can use in C# to get much the same effect as XMLBeans. It’s called xsd.exe

If you give it a schema and some params it’ll create classes you can serialize/deserialize to/from XML. Let’s say you have this simple schema: (more…)

Here’s something interesting. Running this in the Active Directory forest resolves to a real user in the domain:

NTAccount adUser = new System.Security.Principal.NTAccount("domain\testuser");

If you pass this NTAccount to the remote filesystem to add as the owner of a directory, as long as the remote system can resolve that user, everything is fine. However, if the remote system cannot resolve the user, it uses the SID instead. Which isn’t good. However, after the next replication, the SID is replaced by the resolved user. That is good!

UPDATE – 7/11/09

Must have been due to replication leaving the test user hanging around. Starting with a completely new user, if the server where the directory is created can’t find the user, it raises a System.Security.Principal.IdentityNotMappedException

I’ve now got a useable message routing service set up but I’m also getting language overload I think. Not to mention trying to remember debugger commands for each IDE and when to add “;” to the end of code lines and when not! All good fun:

• Matrix. Central ESB with routing, Apache Camel with embedded Apache ActiveMQ. Custom handlers for archiving messages are in Java
• Identity Beans. Java classes for working with the identity information.
• GADfly. Active Directory provisioning engine in C#
• GADflyUI. The front end to GADfly. Windows Forms in C#
• Feeder-test. Simple client to drive the provisioning testing. Ruby

I’ve branched off the C++ version of GADfly as it’s just too much to cope with, all that unicode handling that you have to do yourself and rats nests of pointers to pointers, not to mention keeping track of VARIANTs and remembering to free up allocated memory. It works fine but I won’t be developing it further any time soon, unless I hit a major problem with the C# version.