This, that and next week.

I'll put together the v1.5 build version of dasBlog next week. The v1.4 "PDC build" proved to be "true to the spirit of PDC bits" and turned out to have a couple of problems with the new "dasBlog" theme and some other inconveniences that v1.5 will fix. The true heroes of v1.5 are Omar and the many other frequent contributors to the workspace; I just didn't have enough time to add features recently.

As I blogged last week, I am very busily involved in a exciting (mind that I use the word not as carelessly as some marketing types) infrastructure project on service-oriented architectures, automnomous computing an agile machines. I wrote some 50 pages of very dense technical specification and a lot of "proof of concept" code in the past two weeks and we're in the process of handing this off to the development team. I am having a great time and a lot of fun, but because the schedule is insanely tight for a variety of reasons (I am not complaining, I signed it knowingly), I've been on 16 hour days for most of the past two weeks.  In some ways, this is also an Indigo project, because I am loosely aligning some of my core architecture with a few fundamentals from the Indigo connector architecture published at PDC to that we can take full advantage of Indigo once it's ready. The Indigo idea of keeping the Message body in an XmlReader is an ingenious idea for what I am doing here. In essence, if you only need to look at the headers inside an intermediary in a one-way messaging infrastructure like the one I am building right now, you may never even need to look anything from the body until you push the resulting message out again. So why suck it into a DOM? Just map the input stream to the output stream and hand the body through as you get it. That way and under certain circumstances, my bits may already be forwarding a message to the next hop when it hasn't even fully arrived yet.

One of the "innovative approaches" (for me, at least) is that within this infrastructure, which has a freely composable, nestable pipeline of "aspects", I am using my lightweight transaction manager to coordinate the failure management of such independently developed components. The difficulty of that and the absence of an "atomic" property of a composite pipeline activity are two things that bugged me most about aspects. There's a lot more potential in this approach, for instance enforcement of composition rules. It works great in theory and in the prototype code and I am curious how that turns out once it hits a real life use-case. We're getting there soon. (My first loud thinking about something like this is was at the very bottom of this rant here.) I'll keep you posted.

In unrelated news: Because I know that I'll be doing a lot of Longhorn work and demos in the upcoming months (my Jan/Feb/Mar schedule looks like I am going to visit every EMEA software developer personally), I've meanwhile figured that my loyal and reliable digital comrade (a Dell Inspiron 8100) will be retired. Its successor will have a green chassis.