TransientDataStores

JonUdell is talking about something interesting ...

If XML messages are the transaction currency of a service-oriented network, the argument runs, then there are going to be astronomical numbers of messages. While the messages are in flight, we'll need new kinds of dynamic message stores to index, search, monitor, and correlate them.

Relational databases ... aren't built to handle transient, high-volume flows of irregularly shaped data. ...

Point-to-point integration is out; event-driven communication across a common message bus is in. When you build a system this way, message queues are the first and best way to take the pulse of its real-time state. ...

Later I had a long talk with Blue Titan's chairman and CTO, Frank Martinez, who defined the scope of the opportunity as "things that last from seconds to 30 days." These are arbitrary limits, but they bound a lot of the interesting activity in a system built around coarse-grained asynchronous transactions. When a flight is delayed, triggering a cascade of events related to gates, baggage handling, and meal provisioning, the cluster of events is hot for a couple of hours. Events surrounding a financial transaction are hot for a couple of days, until the settlement cycle ends.

http://www.infoworld.com/article/03/11/07/44OPstrategic_1.html

What does this mean? Specialized short-term transient datastores.

What may this connect with, however obliquely?

• Doing things on a new, shorter time-scale (WorldsWithinWheels)

• A different balance in the TradeOffBetweenReadingAndWriting