Pushing and pulling in XML message exchange

Whenever two systems need to "talk", the nature of the speech acts to be used raises its head.

Do I talk while you listen?
Do I ask you a question and you answer me?
Do I state a fact and broadcast it to anybody who happens to be listening?
Do I sit back and say "go on, ask me a question"?

Some of these choices can be safely relegated to implementation detail. i.e. technically speaking, numerous options can be made to work.

However, some are directly impacted by the boundaries - both physical and organisational - between the communicating parties.

In the Public Services Broker - an SOA based integration infrastructure under construction in Ireland, many of the services connected to the PSB will be hosted by agencies separated from the PSB both physically and organisationally.

As a consequence, it is necessary to analyse the various possible meessage exchange choreographies and take these "business" issues into account. The document Push and Pull Message Delivery in the PSB Architecture is a position paper on the topic.

Although the document is specific to the PSB, the questions discused have a wider applicability in any SOA based on an asynchronous messaging substrate.

Comments welcome.

I guess. Its a problem.

All guesses have bigger guesses, on their backs to bite them.
And smaller guesses within those guesses, and so on, ad infinitum.

With apologies to Augustus de Morgan and all the world's fleas.

Guesswork features in a lot of software. We like it. We want it. It makes software smart. Or does it? Deleterious guesswork in application integration is an ITWorld article that ponders the pros and cons of the guessing game we call data processing.

What is a 'brittle' interface?

Brittle interfaces are bad right? But do you and I mean the same thing by the word 'brittle'?. Read what is a brittle interface? to find out.

A mountable filesystem from your GMail account

Create a 1 GIG mountable filesystem from your GMail account. Sometimes you just gotta smile.

WS-Ectomy

Gregor talks a whole bunch of sense about WS-Yikes. The last para resonates strongly with my own approach:

"""Therefore, I propose to many of my clients to use the WS-* standards as a checklist for their designs. I generally do not recommend they use WS-Addressing or WS-ReliableMessaging (or at least not right out of the gate). I do, however, challenge them by asking, "What is your strategy to track messages in case of error?" or "How do you intend to support asynchronous messaging?" The answer has sometimes little to do with Web Services. For example, the answer to reliable asynchronous messaging might be to use JMS or MQ or another middleware that ensures guaranteed delivery of asynchronous messages. And that's OK. ..."""

It is truly amazing how much you can do just with URIs (applied RESTfully) and an underlying off-the-shelf, boring-as-the-day-is-long reliable asynchronous messaging substrate.

If you have better things to be doing than tracking WS-Palimpsest and struggling to debug WS-InterferencePatterns, I suggest you get an asynch messaging substrate in place, off the shelf *now* and work forward from there.

Choice paralysis and Python web frameworks

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.

More on queues versus resources

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."