Updated Plans of Lokad.CQRS for Windows Azure

We plan to publish Lokad.CQRSv2 beta this week. Documentation and samples will start getting updates afterwards. The actual v2.0 production release will happen, when we have:

• documentation;
• samples;
• at least a week of stable production experience with the Lokad.Salescast, which is currently being upgraded to CQRS v2.

BTW, despite of all these measures to deliver something stable, there already are some brave souls (outside of Lokad) coding with Lokad.CQRSv2 for Azure and providing feedback to improve it.

Now, for the future plans.

Somewhere in v2.x we plan to add a few minor features, which might be helpful for the production experience in building distributed systems (both in Azure cloud and on-premises). These minor features reflect the progress of Lokad R&D with regards to efficient development on Windows Azure and include:

• Porting "Maintenance Console" to the public code (same open source license) as an extensible desktop app used for managing, debugging and maintaining solutions built on top of Lokad.CQRSv2. We are drawing inspiration from RavenDB story here (and the general attitude of Ayende towards building low-friction tools for the developers)
• Adding partial message ordering features to the message delivery scheduler introduced by v2. Obviously this implies persistent message idempotency as well (currently server uses in-memory deduplication scanner). Blog posts of Jonathan Oliver throughly cover a lot of ground here.
• Adding better infrastructure to support the message dispatchers for the sagas and aggregate roots (completely overridable and decoupled from framework .dll, just like it is with the message interfaces and contexts). We are trying to stay as focused and slim as Autofac IoC by Nicholas Blumhardt is.
• File-based atomic storage, scheduling and message processing (just because it's simple to do)

Besides that, there are a few interesting things planned down the road as well. You will be surprised, what becomes possible, when you have a light-weight application bus which is designed for the volatile cloud environment, but can be tweaked to work in the other conditions as well.

Comments

[Jonathan Oliver]

I'm curious to know what mechanism/code you guys are using for your event sourcing persistence. I could just look at the code, but I'm curious to also know about some of the design choices in your event sourcing implementation.

[Rinat Abdullin]

Jonathan,

We don't have event sourcing (a la Greg Young) in production yet. We currently employ domain-level event persistence, where ARs have classical data storage and also publish events. The latter are saved in the domain logs (per system) for rebuilding views as needed and running ad-hoc queries (simple stuff). Proper event sourcing is planned to be implemented a bit later.