Another Short, Free E-Book on a vital Topic – Service Oriented Architecture, Getting it Right

Implemntors Guide to SOAUltimately, I imagine we have Seth Godin to thank for all these wonderful, free books. Here is another one – this one is about implementing SOA, and from Joe McKendrick’s description, it is part implementation guide, part inspiration to get started now, not wait for the mythical day when your organization’s blueprints for the Hanging Gardens of Babylon of enterprise architecture are finally complete.

The e-book is available as a free download here, and a print version can be purchased for $20.00 here.

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

Fine, SOA may not be a City. What about a religion?

Rob Eamon has offered some compelling, well cited arguments (corrections?) in regards to a previous post of mine describing the image of SOA as a city/society that I selected from among various alternatives to use as a mental model. See the comments of that post for a full record of his take on things.

I can’t help but wonder, though, assuming his understanding is the original understanding, that the original “scope independent” definition he has laid out for the term SOA is mutating or fracturing into a different meaning, or more probably collection of meanings, as the concept is becoming more and more mainstream. Perhaps the mutation, if is real, is fueled by relative “laymen” from such out of the way places as the SMB (such as myself) as we attempt to understand SOA and become practitioners, which perhaps wasn’t common until more recently.

Or perhaps I say that entirely defensively, not wanting to believe I could have missed the mark by such a large margin.

In any case, I certainly have no other option than to concede that I was incorrect in my naive belief that I had found for myself a way of thinking about SOA that, at least in a purely conceptual fashion, could exist at an abstract level above all the tumultuous debate.

Perhaps believing in an image of SOA that encompasses all possible schools is as foolish as believing in an image of god that includes all other religions. I never get used to how much technology feels like religion to me at times.

Maybe things would be more straightforward for everyone if there were named schools of thought one could subscribe to, and then it wouldn’t be so tempting to say “This, well THIS is SOA, and that, well that is something that may resemble SOA(maybe), but in fact it is nothing of the sort.” Rather I could just say “I am a Soascopist” and you could say “I am a Soastylist” and, like religion, an argument about which is right would inevitably continue to rage. But, when the uninitiated like myself walk into a room of people shouting different definitions over each others heads, we would clearly know we needed to pick a school, learn the dogma and start shouting back, or we could state ourselves as agnostics, but we would be less inclined to try and synthesize the “truth” from all of the various contradictory opinions, which turns out to be a rather futile effort.

Then, when the holy war breaks out (and perhaps it already has), the SoaScopists, the SoaStylists and all other various sects of Soaists will take up arms together beneath a common standard and ally themselves against the RPCists. Gifted with superior agility, close strategic and financial alignment with the emperor, and extraordinarily loose coupling, the Soasists will relegate RPC to the level of an outcast technology, kept on life support on the outskirts of the kingdom via a flimsy service adapter, until some data center technician coldly pulls the plug, changes a value in a routing table, and the lights go out for good.

Of course, however it shakes out, we’ll still always prostate ourselves before the dollar, one way or another.

Amen.

(BTW, the holy war is just a joke, not my new personal metaphor for the relationship between SOA and RPC)