You may be familiar with the magnificent masterpiece of Escher called "Relativity". We see relativity everywhere -- on Saturday I've called home from my hotel in Burlington (since then I've moved south, and now I am in Hawthorne, NY) and told my daughter that I am sitting in the hotel waiting for the snow to end, in order to get out, and she said -- "how lucky you are to see snow", I have not felt lucky to see the snow, in fact, it kind of disrupted some pans I had, but in the world of a person that lives in Haifa, snow is a rare thing that occurs once every 20 years for a short time, so it is an attraction. At some point in my past I have been teaching a basic AI course, and the teaching assistant has taught the students Lisp. I have looked at the end of the semester on Lisp code produced by students - some got it right and wrote pure recursive program, and some wrote code that looked like Fortran thinking in Lisp.
The same relativity exist when dealing with event-based applications. Some people understand how to construct such applications, while other people think in other paradigms like request-respond, and are trying to do some blend here. It is perfectly OK to do an hybrid approach, but this should be a result of careful design, and not by chance. Bottom line - we need a methodology for constructing event-based applications and tools to support it - this will somewhat different kind of thinking... more about this topic - later,
5 comments:
The loosely coupled and indirect way of sharing information that pub/sub with events/messages is indeed hard to get.
Looking at the "failure" (in some sense) of SOA. We had a chance to create a new architectural style which did not create a mess of tightly coupled systems on the enterprise level. Now many people are creating nightmares by connecting each system with each other system by way of SOAP calls and implicit assumptions on data content.
What would be great is a name. A name on a methodology which is pub/sub and does everything loosely coupled. Then we could say; "We do X, Aaah you do X, very impressive", today we have to start over again each time when explaining to business managers why it is a bad idea to request information. Event better would to have a book; "Look here, we do as in this book". And even better than that would be to have something from the great minds of Gartner; "Gartner says this is the way to do it"
My hope is that soon emerges something really hyped concept at the executive level which really requires event driven architectures in order to be implemented. This would create a demand for our nice EDA stuff from the upper levels in organizations as I'm pretty sure that the executive around the world generally don't care at all how we do our stuff. But if EDA would be the only way to solve business problems, then we prevail...
This discussion should be posted on the CEP Forum. Style in EDA is really open.
As for pure Lisp, it all depends upon the problem. McCarthy had a totally naive idea that Kleene recursion equations would be the basis for a computer language for AI. Those who built the Lisp1 compiler found that pure Lisp was totally inefficient for, say, coding a Lisp interpreter. So the "Prog" feature was added - an Algol like sequential statement with conditionals and loops. I have to take the blame for that. But it speeded up the Lisp compiler (in Lisp) by a factor of 10**3.
Oh, and one of the ways the Prog feature did that was to reduce the number of garbage collections. Recursion is extremely heavy on memory!
David,
The Lisp example was an analogy, and not an intention to re-open the historical Lisp-Prolog debate.
The question about - pure EDA vs. EP as programming constructs that can be used in request/response mode is still open and has various opinions.
cheers,
Opher
You are so right, Opher...
I've put it this way...
-Jack
Post a Comment