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:

• 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

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

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

Create Bullet Graphs with Google Charts in 7 Easy Steps

I haven’t paid much attention to Google Charts so far, but I have enjoyed Stephen Few’s “Bullet Graphs.” A bullet graph is an extremely condensed sort of bar chart that shows the current value of a KPI, and various ranges such as unacceptable, acceptable and target, and an optional indicator line that can mean several things. Anyway, here is an example of a bullet chart (from wikipedia):

 

 

This blog post referenced below was referenced in Stephen Few’s blog this morning and describes the several easy steps required to create a bullet graph using the Google API. Being able to easily throw these things up, ad hoc, in any web page is pretty phenomenal, if you ask me. The image below is actually a Google Graph:

 

Here is the link to the guide:

DEALER DIAGNOSTICS » Blog Archive » Create Bullet Graphs with Google Charts in 7 Easy Steps

An annotated list of some open (free) data sources on the Internet

By data sources I mean programmatically consumable databases. I haven’t spent enough time with this article to judge the quality of the data sources, but I did pop onto one of them (Freebase) and finally got a flash of insight into the potential of the semantic web. Anyway, these lists from Read Write Web are always well thought out and include top quality sites, so if you’re ever looking for some piece of data to feed a hungry app, this list may be a good place to start.

http://www.readwriteweb.com/archives/where_to_find_open_data_on_the.php

JSON.NET – A library I’m certain will be of use in our new service oriented lifestyle.

http://www.codeplex.com/Json

 

This guy handles JSON serialization, has LINQ support.

Useful API List Post

This post will document the useful API’s we run into from time time and don’t want to forget about, but are not ready to use right away.

First, here are good sites to check if you’re looking for an API:

API Finder – cloud service repository

Programmable Web – cloud service repository

Strike Iron – commercial cloud service repository

Sharp Toolbox (.NET libraries, some open source, some not – pretty much everyone lists their .net tools here as soon as they are released, so it is a good place to start the search for a library)

CodePlex – Obviously this only hosts open source stuff, but some of it looks to be pretty high quality.

 

Random API List in no particular order

IfByPhone – this is another telephony API – apparently it allows a broad number of telephony tasks which could prove useful in the elusive future where we have time to put that extra coat of polish on our applications and wire in the flashing LED lights while magic fairies serve us Margaritas in pixie-dust rimmed glasses.

WorldTimeAPI – here is what may prove to be a very useful tool. This API will take a lat/long coordinate and provide the time zone, daylight savings time, etc.

PilotOutlook – this is an airport info web service. Their license is non-commercial, but maybe they have a commercial version. This one was too up our alley to ignore, though.

Scribd – this is a really interesting service. They have a flash based, you-tube, html-embeddable PDF rendering control, and the API provides a number of other useful sounding services. A document library might benefit from these. From the site: “The Scribd API is a REST-based API with methods for uploading, converting, editing, deleting, and searching documents. Using the API, you can use Scribd as a back-end for an application that needs to process documents, without needing to write a document processing system yourself.”

Open Calais – this is a semantic web service that takes content, performs a semantic analysis on it, and extracts people, places, technologies, etc. Can be used for analyzing data feeds, performing a more intelligent indexing of data for searching, or simply presenting users with useful context information about a document they are viewing.