Like an
EnterpriseDataFabric (
http://en.wikipedia.org/wiki/Enterprise_Data_Fabric), but less 'enterprisey'.
By analogy from
SwitchFabric, a 'data transport layer' that can resolve, cache and distribute queries and events from disparate
ApplicationProgram s,
DataBase s and
FileSystem s into a single live and persistent
DataSpace. A possible solution to software
ImpedanceMismatch, and a way of making
EventDrivenProgramming less painful by making it pervasive at the system level.
Something computing needs to evolve before we all go insane from trying to get incompatible systems to talk to each other - even within our own desktops.
A similar concept to the
SemanticWeb, taken into the domain of processes.
ResourceDescriptionFramework (especially projects like
HayStack) and
RepresentationalStateTransfer are possible first steps toward a
DataModel on which a
DataFabric could be built. Also similarities with
UnixPipes and
FlowBasedProgramming, with
ServiceOrientedArchitecture's
EnterpriseServiceBus,
LindaLanguage's
TupleSpace,
BlackboardMetaphor, and
PlanNineFromBellLabs. A somewhat higher-level idea than
DataBusPattern.
Since a bulk of the work of interconnecting data from separate systems involves executing code (even small utility functions or scripts), a working
DataFabric may need to be a
ComputeFabric as well, thus being a kind of
ApplicationServer for
GridComputing. But less 'enterprisey'.
This is all pretty interesting, but we'll need to solidify some of these concepts into easy-to-digest examples or user stories before further discussion. It is highly unlikely anybody not already intimately familiar with all these disparate technologies will follow all the links and investigate everything so as to participate in a discussion of the makeup of such a fabric.
And the real question is:
WillItBlend?
Having read the
ReactiveDemandProgramming and
ActorVsAgent pages, this seems to be pretty much the same idea. It's difficult to reduce into specific examples as they haven't really been implemented yet. It's not about the intimate details of all the above-mentioned technologies - because they're all doing very complex things rather clumsily - but about a very simple essence common to them all. Something like massively parallel
DeclarativeProgramming with a demand-driven pipe model. My intuition is that this paradigm will fit very nicely with a
ConcatenativeLanguage.