We’re using Elgg as the basis for building the UHI Communities network and as we’re doing quite a lot of customisations of the core code, we need a way to manage Elgg releases and how they get merged into the communities code. The requirements are simple. All source code must be under version control. There are other ways to manage vendor code that don’t version the actual source code but I did a bit of research and found the ideal solution. The Third Party Codeline SCM pattern. I initially got the basics from the superb Pragmatic Version Control using Subversion and there’s another summary here and an article here. As ever, a picture is worth a thousand words:

The SOA Project is basically an amalgamation of a couple of projects that were waiting to be taken on, namely linking Blackboard and Elgg to SITS, with the requirement that changes in Blackboard objects have to be replicated in the institutional “data silo”, which isn’t SITS. So what is it? The plan is to rollout Novell Identity Manager (IDM) to handle provisioning of  the core systems, eDirectory, NDS and Groupwise, replacing the framework that’s been running for the last six years or so. Whether the rest of the applications that make up a user’s online portfolio should be plumbed in to IDM is a current topic of interest. Novell discourage custom IDM driver development, which to me either means they don’t trust third party developers or they don’t trust their product. I’ve seen this before. Microsoft discouraged third party NT4 driver development as kernel mode drivers are very difficult to develop and lots of people were doing them, badly, giving NT4, which is the best OS Microsoft ever produced, a bad name. So my gut feeling is IDM is either too complicated for the average bod to develop against, or it’s too ropey for anyone other than Novell to handle. A quote from the DirXML documentation sheds some interesting light on the latter:

“… DirXML does take some precautions when calling into a native driver [C++] … All calls into the native driver are protected by a try-catch block that catches all exceptions … If an exception is caught … the driver is shut down … On Win32 this works well. On NetWare however, it does not work at all. At the time of this writing it is unknown how well this works on the Unix platforms” (my emphasis). (more…)

I’ve updated the diagram of Identity Manager with the latest terminology but I’ll leave the original intact as it’s interesting to see the changes. Here’s the latest version:

I can’t introduce this as I want you to read it and form your own opinion. All I’ll say is, simply wonderful:

A programmer’s view of the Universe, part 1: The fish

I’ve got a meeting next week to discuss the replacement of the account creation system I developed about 6 years ago and which has been running continuously since then. The plan is to replace it with Novell Identity Manager and use DirXML to hook up the various systems that the current system provisions. At the moment the system links SITS to Novell NDS via LDAP (accounts) and NDAP (home directories) and Groupwise via COM. So how does all that translate into IdM lingo? The following diagram gives an overview of how IdM/DirXML interact with external systems:

Ian Young has some interesting ideas on metadata interchange between federations, which you can read here. It deals with aggregating metadata from entities in different federations, making them appear as if they are part of a specific federation. As I’ve just finished implementing federation sensitive metadata and trust handling for Guanxi, I might as well digest the proposal and give my opinion on the matter. What’s that you say? Opinion? Surely a rant? Not this time I’m afraid. I thought it would be interesting to approach it from a software point of view. Ian is proposing a federation could aggregate metadata for all entities that are members of another federation, much in the same way it aggregates metadata for its own members, as in the case of the UK Access Management Federation metadata. As this doesn’t happen at the moment, entities who live in multiple federations must aggregate the metadata themselves. This can be seen quite nicely in the Guanxi IdP and SP, where you can register local entities, if you want to do local testing or just want a local intranet of entities:

Started looking into a new project with Naomi, to integrate Blackboard, Elgg and Sympa with SITS, our student records system. First cut will use ServiceMix and ApacheDS. Off to write a whitepaper for the next team meeting;

I recently spotted this interesting post on Bediun star-lore and contacted the blog owner to see where I could get a copy of the article. Turns out it’s available on JSTOR but for a fee, unless that is, you have a subscription via your academic institution, which I have. Not only that, I accessed it using Guanxi. It’s nice to see your software at work!

I’ve now defined a workflow which seems to fit the project. There are two paths through the workflow, one for migrating resources to the federation and one for reporting and fixing problems with previously migrated resources or the other components, such as the IdP or the server itself:

That’s the Guanxi metadata and trust management merged into HEAD from tag METADATA_MANAGEMENT_011008. Tagged HEAD as POST_METADATA_MERGE_061008.