The Freak Parade

Yet another community gift – this time an e-book about Domain Driven Design. You can buy a print version but the PDF is free, and small enough to easily print out yourself and bind with a clip. The book is by the founder and editor of InfoQ.com, and is billed as a summary of Eric Evans (this one, not this one ) famous book, Domain Driven Design.  At this rate I may never have to purchase another book again.

A discussion on the nServiceBus discussion list has been taking place recently regarding how to have durable messaging on remote nodes, such as smart clients, where the deployment and maintenance requirements of MSMQ aren’t tenable. The main concept being tossed around was a local database to hold un-sent messages at the remote endpoint that could be attached to any transport, making any non-durable transport durable. Ayende went off to build a prototype (but hasn’t reported back, so I’m not sure if it is still in progress, although there were strange noises coming out of his blog recently that suggest he might still be working on it) and it was mentioned that Evan Hoff was building such a thing using Berkeley DB.

One advantage of both of those options is that durability could be bolted on to any transport, such as HTTP or one of the non-durable WCF bindings, without much fuss. However there is at least one commercial service that I’ve talked about before, Linxter, that provides an internet-oriented message transport (or Internet Service Bus, ISB) with lots of cool features. What I didn’t realize, until today, was that the Linxter client API does exactly what was discussed at the NSB forum – provides a local cache for messages via an embedded DB (SQLite in this case), essentially enabling an x-copy deployable, durable, asynchronous messaging endpoint.

Of course, it doesn’t have the flexibility to attach “durability” to any conceivable transport – because Linxter is it’s own transport – but in most cases I don’t think that should be a big issue. The only question now, is, how much will it cost? Apparently pricing will be announced with Beta 3, which is scheduled for July 31st. Version 1.0 is scheduled for August 15th.

Here is the e-mail I received from Lixter’s Jason Milgram explaining the local queue:

Yes, the Linxter API queues messages locally (does this in Beta2), and does not take them off the queue until they are delivered. In Beta 3, we will offer additional reliability and efficiency for file transfers by enabling chunking. For example, let’s say you are transferring a 100MB file, and after transmitting 70MBs you lose your connection,…when the connection is re-established, it picks up from where it left off. We felt that these queuing and chunking features were pretty important especially with wireless connectivity becoming the norm.
The ISB is a distributed system, with failover built into the SDK (API)  as well as on the ISB. If the API cannot connect to a service on a particular set of clustered servers, it will failover to another set of servers. We can also dynamically reprovision server and service assignments for programs.

And here is the updated roadmap [emphasis mine]:

Release dates:

• July 31st        Beta 3
• Aug. 15th        Version 1.0

Beta 3 Overview:

• Linxter SDK for both .NET and Java
• Reorganization of methods for on demand and scheduled sending
• Enhancements to Web Manager user interface
• Web Manager support for both IE and Firefox
• Standardization of API local datastore to SQLite
• Availability of Quick Starts – feature based sample apps

On our website we have added the following:

• Linxter ISB implementation options: http://linxter.com/implementation
• The first of several screencasts: http://linxter.com/screencast
• An updated Getting Started guide:  http://www.linxter.com/GetStarted
• A company blog: http://linxter.com/blog