In one of the previous blogs I have cited the "hammer and nail" blog written by Louie Lovas from Progress and said that I don't have the honor to know the author personally, so he has sent me a note introducing himself - very nice of him to do that ! Mr. Lovas recently has written another blog entitled: "Hitting the nail on the head", in this blog, the opinion is that the current trend is separation between the presentation layer, logic layer and data layer, and that using SQL for event processing is going backwards - since it mixes the business logic layer and data layer - if I understood the reasoning correctly. I agree with the end result of the author about the fact that SQL may be inappropriate language to express some event processing patterns, and I have written about it before, I also big fan of "separation of concerns" and other separations as a software engineering and architectural practice. However, these two things are independent, in the past, when we worked on active databases, this has been indeed under the concept that business logic is embedded inside the database logic, but, this has nothing to do with the API. We can still have separation to architectural layers on one hand, and share the same API, on the other hand; there are even some benefits in doing that - such as reducing the number of APIs. Thus - from the architecture point of view, I don't see any problem in using SQL-oriented language for event processing; the same (or similar) API can appear in various architecture layer (and in various roles).
the problem, as said is pragmatic, and stem from the SQL semantics and its fitness to event processing. In fact, in the course I am teaching we'll probably do with the students some experimentation on that.
More - Later
No comments:
Post a Comment