The city of New York has issued a 3 cents value stamp for its 300 anniversary, I am not in the stamp printing business, and wonder how long stamps will survive, but the blogger tool tells me that this is my 300 posting on this blog, in almost two years. Since recently I am dealing in languages, today I'll share some thoughts about declarative programming and its implications on event processing. John Bates told in his DEBS keynote about his experience, in the assumptions they had when developing Apama in the lab, and how these assumptions were slightly changed when got out of the lab. This is a phenomenon that I know well from a few times over my life that I have been involved with getting ideas from the lab to reality. Of course, the closer that your assumptions made in the lab are to reality, the faster time-to-market you have, and better success probability. Among the opinions that I used to hold is that declarative programming is always superior on imperative programming, in imperative programming, people need to work difficult needlessly, while in declarative programming, programming is more elegant and easier. I did not really changed my mind, however, reality shows that its ain't that clear cut. Getting to a neighboring area, it is well known half-secret in the business rules industry, that while all BRMS products support RETE style declarative inference rules, most users prefer to use a more imperative looking "sequential rules; I think that the reason is that in inference rules the flow is hidden, each rule is defined individually, and the flow is derived from the fact that some rule derives some fact, and some other rule has such a fact in its conditions, but this makes all the programming as "programming in the small", and the "programming in the large", controlling on how various rules relate to each other, does not exist in this programming style. It turns out that it is important for users to have visibility, and even control on the programming in the large aspects. Coming back to event processing, I believe in a combination of declarative programming for the programming in the small, i.e. to define any individual event processing agent, and making the programming in the large, i.e. the event processing network, explicit. This is not really an imperative model, since the EPN can be implemented in various ways, but it is not pure declarative either. We see that this type of programming model is getting traction.I'll discuss the various dimensions of event processing languages in depth, in further postings - stay tuned.
Here is a picture I got recently from Matty Cooper, from EventZero, who made all the way from Australia to Nashville to attend DEBS 2009. This picture was taken during the event processing language tutorial
5 comments:
Hi Opher - actually the main BRMS tools tend to hide, in true MDA style, what the algorithm for rule execution is (ie Rete or sequential or whatever). The reason is they are usually mapping from a high level rule language or notation, such as a decision table, that can be executed sequentially or using an inference engine. Buf if you are not inferencing and just firing 1 rule, why bother with a Rete engine?
On the other hand, BREs often use flow diagrams, like some ESP/CEP tools, to connect declarative rulesets or other rule entities together in an execution chain. So really then end up mixing sequential (ruleflow) and declarative-or-sequential (rulesets).
FYI OMG PRR provides both declarative and sequential rule semantics, and is investigating a possible Decision Model and Notation standard for the BRE / BRMS modeling parts... through your colleagues at Ilog and friends at TIBCO of course!
Cheers
Hi Paul. True - there is an inclination to go for higher level models, and the result is a mix of flow and declerative style, which was exactly my point. My observation is that the RETE engine, while exists, in BRMS products, in used much less than its potential to be used, due to the fact that the users feel more comfortable with explicit flow.
cheers,
Opher
Hello Opher,
- With this photo I have evidence for my coworkers that I was at DEBS tutorials and not drinking margaritas!
- I've heard many smart people, including you and Adrian, counsel against dogmatic insistence on declarative rules in every rules implementation. I am still stuck in my dogmatism that all processes can be reduced to declarative rules, however, as I generally see this as a failure of the rules analyst to analyze imperative rules into their underlying declarative basis in knowledge. I think I could agree to the compromise of programming in the small and the large, as you say, if there was an intuitive, general reason why many implementations require this concession. I haven't been able to think of one.
cheers - Ken
Hi Ken. My dogma is that there are no dogmas. I come from the same school that thinks that pure delarative programming is better, and sure -- everything can be expressed by declarative programming only. What I pointed out that in reality this ideas does not seem to fully catch up, and some compromise is often applied, and we cannot ignore the reality, but try to understand it, and see how we can adjust our thinking (maybe make the declarative programming more appealing? use hybrid models ?).
cheers,
Opher
Post a Comment