There is a phenomenon in psychology, I cannot remember its name, to do with too many choices creating a paralysis of choice. e.g. If you have 3 T.V. stations to choose from , you flick through 'em, pick one and watch it. If you have 300 T.V. stations to choose from, you are swamped in choices and end up flicking all day, not watching any one thing.

There is a metaphor in philosophy, I forget its name (I'm bad with names, can you tell?). Somebody had a donkey - a very logical donkey. The donkey is tethered within equidistant reach of two yummy bales of hay. The donkey dies of starvation because there is no logical reason to pick one bale over the other.

Thusly introduced, I recommend PyWebOff.

posted by Sean 1:59 AM

[Link] . . .

Mark Baker writes:

Whenever I want to do the queue thing, I use two resources; the
"business resource", and "the inbound message queue for that business
resource" (though of course, as a separate resource, it need not be
used only for the business resource). I then subscribe the business
resource to the queue, such that messages POSTed to the queue also are
forwarded to the business resource. FWIW, I've been using mod_pubsub
recently to manage the queue resource (as a topic maintained by its
router) in some work I'm doing on the side.

But doesn't this create tight temporal coupling between the POSTs and the business resource?

It strikes me that this scheme essentially achieves a "Got your message, I'm dealing with it right now. Please stay here in reception until I get your answer for you."?

I really value temporal decoupling. No implied correspondence between asking to modify a business resource and the business resource itself. What I'm after is:

"Got your message. Thanks. I can assure you that it will be taken care of by the Business Resource in due course. You can safely go about your business now, here is a tracking URI. If you need to know what the state of things are, just call GET."

posted by Sean 1:10 AM

[Link] . . .

Mark Baker says:

"Show me a message(*) and I'll show you a representation of the state of some resource."

I agree with that but would add that in my conceptualisation of SOA, a "resource" is some business meaningful concept like a customer or a widget.

A "service" is what you get when you bind such a resource to an asynchronous communications channel that you then expose to HTTP.

Simply put, business resources should be "one step back" from HTTP IMHO. When you send non-safe messages to a resource (e.g. POST/PUT), you send them to its inward bound, asynch message queue. You do not directly interact with the business resource.

What you get back from a resource with an idempotent GET, is a "stable data"[1] representation of the resource at time T. It may or may not be the same as the current resource and it certainly does not take account of any pending non-idempotent updates.

I find this resource/service distinction useful and find the temporal decoupling absolutely invaluable. It is, as far as I am concerned a cornerstone of any useful SOA.

[1]I recommend Microsoft's Pat Helland on the subject of "stable data" e.g. http://prade.microsoftemea.com/content/ARCSYM1_Helland.ppt (especially slides 9 and 11).

posted by Sean 10:45 PM

[Link] . . .

Breakthrough syndrome strikes again.

posted by Sean 1:03 PM

[Link] . . .

I have had e-mail from two people asking if the Python meetup in Dublin next month is for for Python users only.

No, anybody interesting in discovering the one true way...

...Ahem. Sorry about that.

Anybody interesting in Python is welcome to come along.

posted by Sean 12:58 PM

[Link] . . .

A while ago I wrote an article for ITWorld entitled Chance encounters of the electronic kind. Serendipity, luck, chance, the road less travelled, gardens of forking paths, all play bigger roles in information discovery than we tend to like to admit.

I'm convinced that one of the reasons bookshops are still going strong is that they have an unparalleled ability to allow you to stumble upon stuff by accident. It is part of what makes libraries such wonderful places too of course.

The Flamenco search engine tries to bring some of that to the electronic world. Much needed IMHO.

posted by Sean 1:38 AM

[Link] . . .