The Physical Web - by Google

Google recently revealed the "Physical Web" project.  This project is aimed at "interaction on demand" which will be a standard way that everybody will be able to consume data from devices connected to the Internet (AKA "Internet of Things") without the intervention of applications.   
This idea reminds of the idea of the grand challenge posed by the Event Processing Manifesto that was the result of the Dagstuhl seminar in 2010 and talked about "event fabric".     The "event fabric" challenge went further than get events on demand and also included processing event patterns on demand which I believe will be the next step to create access for everybody.  The ability to compose patterns on demand by everybody is a key to making this real-time data useful and complete the IoT revolution....  I am planned to give a talk related to this idea in early November in a workshop adjacent to the ACM Multimedia conference in Orlando... Will write more on this later...

On Parallel processing and Event Processing - Take I

My travels in the universe have taken me to Brussels (somehow, I have never been in Belgium), for meetings regarding an EU project we intend to propose for the next call, I'll Blog about this proposal when it will be more mature. As we are working for a while on parallel processing related to event processing, I am looking at some of the related work. I came across an interesting article in Gregor Hohpe's Blog, stating some of the assumptions behind the parallel programming model of cloud computing. Gregor defines these assumptions as the "new ACID", relating to the old ACID properties of transaction correctness (Atomicity, Consistency, Isolation, Durability). Gregor provides four new ACID properties for the cloud computing: Associative, Commutative, Idempotent, Distributed. Gregor explains the notions:
While the original ACID properties are all about correctness and precision, the new ones are about flexibility and robustness. Being associative means that a chain of operations can be performed in any order, the classical example being (A + B) + C = A + (B + C) for the associative operator ‘+’. Likewise, we remember commutative from junior high math as A + B = B + A, meaning an operator can be applied to a pair of operands in either direction. Finally, a function is idempotent if its repeated application does not change the result, i.e. f(x) = f(f(x)).

Having these properties enable paralleling the operations and collecting the results, the principle behind Google's MapReduce. In order to take advantage of this way of parallelism for event processing functions (or agents), we need to check whether these properties are satisfied. In event processing -- the temporal dimension and the fact that some of the patterns are not associative, some are not commutative, and some are not idempotent, may issue a challenge. This does not say that the parallelism idea is not valid for event processing applications, it is just saying that the parallelism is influenced from the semantics of the event processing network. I'll drill down into this issue in future postings.