The XML Summer School 2006

The XML Summer School was very interesting and enjoyable again this year. Highly recommended.

This year, I talked on the subject of Web Services and SOA.

At some point during my talk, Paul Downey took a photo.

JINI, Asynch Message Queuing and all that temporal decoupling stuff

An old hobby horse of mine this temporal decoupling thing. I cannot help beating on that particular drum as I see it as a really important concept that deserves to be better known.

Take a squint at OSCS for example. Using Amazon's S3 to splice a JINI-style asynchronous IPC layer into your application with very little heartburn compared to actually using, say, JINI locally. (JINI is powerful stuff but the last time I set it up, it cost me a week. Things may have improved since then.) This sort of infrastructure is a pain to set up and costly to keep running. If the cloud can do it for you...

Then there is the idea of using this layer to build an async message queue abstraction and using the message queues to orchestrate scalable web services where the processing can be done on any old machine (or machines) while the message queue layer, hosted in the cloud, does all the scalability/reliability etc. etc. Again, if the cloud can do it for you...

There are some patterns here which will grow in importance and popularity over the next few years. Are we seeing the virtualisation of the middleware layer? The outsourcing of the "ilities" of web apps?

Obviously, for some application areas this sort of out-sourcing of the middleware layer will not be a runner but for other application area, I think the whole area has significant legs.

To be provocative : A trendy new mashup without an asynch message queue handling all that nasty non-functional aspects of application design (like scalabilty, reliability, availability etc.), is either (a) only half a mashup which will generate blue smoke if (shock horror!) it becomes a success or (b) a full mashup that is way too expensive to operate and run to be around for the long run, unless its owners get subsumed into some mothership or other.

SEDA

At the recent XML Summer School I mentioned SEDA - Staged Event Driven Architecture - as an interesting approach to temporal decoupling a form of decoupling which I believe is vital to any non-null definition of SOA.

I think of it now because it is relevant to Restaurants, roller coasters and randomly failing web applications.

Who you are

A while back I asked "Who are you?.

I recieved somewhere in the region on 40-50 replies via various media. Here is a distillation.

• You are interested in Python/XML/Web Services/SOA and a goodly number of you are interested in broader areas of dynamic typing/information integration/distributed systems.
  
• Many of you like the ITWorld articles citing humour, interesting/odd-point-of-view and writing style as reasons.
  
• You mostly work in IT in the commercial sector
  
• You live in North America/Europe
  

Thanks to all who replied.

Fast pipe. Always on. Get out of the way.

"I used to think that it was only a matter of time before the web was 'fixed' to provide reliable message exchange functionality without which, B2B message exchange on the Web would be impossible. I do not think that any more." -- Fast pipe. Always on. Get out of the way.

Restaurants, roller coasters and randomly failing web applications

"this is a temporally decoupled web application folks, POST your required transaction, take an idempotent URI and poll for latest service information."--
Restaurants, roller coasters and randomly failing web applications

Planned downtime notice

This blog will be down for the next two weeks in order to facilitate the rebuilding of the tattered synaptic interconnections of its author.

Normal service will resume third week in August.