Linxter Offers Durable Messaging for Remote Clients

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:

SimpleServiceBus Getting Started Guide

SimpleServiceBus Overview & Architectural Description

I have posted a comprehensive overview of Simple Service Bus, including an architectural description, in the form of a PDF document available here. A few images from this document are included below.

image image

SimpleServiceBus on CodePlex (a fork of nServiceBus)

A new ISB (Internet Service Bus) in beta testing – Linxter

Home

Similar to BizTalk services, minus the workflow/identity piece but plus a fairly robust security model and web based management dashboard, Linxter(http://www.linxter.com) provides a secure, queued transport for .NET applications. Essentially the service acts as a hosted messaging queue with an extremely simple (in a good way) API and an interesting ability to optionally send file attachments with your messages, which right off the bat gives it an edge over MSMQ over HTTP in my mind. Applications using this API will request registration with a central account on startup and security settings determine if the connection is automatically granted or if an administrator has to manually grant access to your bus to the endpoint. Once access is granted, endpoints (via the Linxter SDK) can send messages and receive messages in either an “on-demand” pull model or an event based push model. The service also supports broadcasting messages to multiple endpoints.

This isn’t something that could act as an ESB, but it could certainly act as a transport for an ESB. The service doesn’t have any pricing announced and the user agreement forbids production or commercial use, but it is something to watch if such a service would be useful to you.

In our case it would be perfect for connecting client systems to our hosted solutions without having to deal with ensuring MSMQ w/HTTP support is properly installed on each endpoint machine, and ensuring the proper queues are set up, etc. Much easier deployment and maintenance for remote nodes not in our firewall. If all your endpoints are inside your firewall, a hosted queuing service may be of little value, but if you have endpoints in the wooly wild, a service like this could be invaluable, taking care of endpoint authorization, identification, and all the rest.

Here is a link to the current stage of development, which appears to be nearing the end of Beta 2

Run ActiveMQ as a Windows Service

Instructions from Apache are here

ActiveMQ and NMS (via Spring.NET) Resources

These articles detail simple, but end-to-end examples.

 

ActiveMQ via .NET Messaging Overview

Request Response

Pub/Sub

Transactional Message Processing