[BarcampLondon3] Message-Oriented Architecture (Matt Bidulph, Dopplr)

HTTP not ideal for asynchronous stuff (“Are we nearly there yet?” “No.” “Are we nearly there yet?” “No.” “Are we nearly there yet?” “No.”). Message-passing architecture is better (“Let me know when we’re there” … “We’re there!”).

Also useful for clusters, multi-core machines etc.

Erlang (also Scala, Haskell, E etc) are becoming interesting because they operate using messages. Not that different to pure OO. No shared state. Scalability doesn’t come for free, but it’s much easier.

Spread, MQ, JMS etc: publish and subscribe. Stick a message on a topic or queue and any subscribers receive it. Allows very loose coupling. One-to-many, with publisher not needing to know about subscribers.

Comet allows a connection to be held open between browser and server, rather than having to poll.

Jabber can be used to return future results for a search (for example). “There will always be more pictures of kittens.”

Worker queues remove expensive calculations from synchronous tasks (eg calculating Dopplr coincidences does your own immediately, and queues a job to calculate coincidences for all your contacts).

Using JQuery you can create your own events in a browser. Becomes more like traditional GUI programming.

Extreme late binding: combine data and code in application (eg javascript and data in browser – mashups).

The Internet is the computer.

First question: “How does Dopplr work?” :-)

Interesting point about hiring: go for the people who are good at the cool stuff (Erlang, Haskell, etc), because they’ll probably be really good at the workaday stuff too, and are obviously interested in the field.

[tags]barcamplondon3, messaging, erlang[/tags]