This is the Computer Science building at the Technion; yesterday I have started to teach an event processing course there (in the previous semester I have taught in the Information Systems Engineering program, which is my academic home for many years), the course is given as an "advanced topics in computer science" course, and the students that have shown up were mostly graduate students from CS as well of EE (there are software people in EE also). Unlike the previous semester in which the students projects evolved around validating the solutions that different vendors put for the EPIA book's website, this time I would like to concentrate in the project level about the view of those building event processing platform (this is a slightly different view). The first class is always an introduction, since the students don't have a clue about what event processing is, thus I am starting with some examples about what is it used for.Always there is somebody who asks the question -- what is new, haven't such applications done in the past also? My answer is, consistent with the answer I am giving to this question for years, event processing does not bring any new functionality to the table, it takes functions that people have done in one or other way using regular programming and make it both -- easier to use since it introduces high level abstractions (analog to the abstraction of database query against the way we did database programming in the distant past, and other abstractions), and providing platforms that can execute these abstractions using optimizations specific to these abstractions.
I am also talking about the event-driven decoupling programming vs. the more traditional request/response.
One thing that I am making sure that the students will understand is that (like databases) event processing can be used for many different purposes and is not bound to a single type of application, or single industry. I am doing it by starting with 10 examples that are quite distinct (taken from chapter 1 of the EPIA book), and concluding by trying to generalize some type of applications, using the picture below (taken from an IBM academy study a few years ago that examined what event processing applications are), this is just one of possible classifications.
This is an important thing, since there are some misconceptions around.
As I have written in a previous posting, event processing does not have a single purpose.
Creating event aggregations to check key performance indicators is certainly an application, but not the only one; likewise "detecting threats and opportunities in the event cloud" is a phrase going around (I heard it first from Roy Schulte, but I don't know if he is the copyrighter), and indeed, this is an application of event processing, but many event processing application detect neither threats or opportunities, but serve for diagnosis, or operational decisions. The message - event processing is a discipline with set of concepts, and various ways to implement these concepts that serve many purposes that need event-based computing. I Shall write more about the course as it will further develop.
1 comment:
It's great to have the chance to work with students and let them do projects in teams. There are always very creative solutions and investigations which would never be done otherwise. It's very productive and interesting for both sides.
Perhaps we will be able to realize our virtual university course "Beyound Simple CEP / Ubiqitous Event Processing", I have not yet given up and there is a starting dialogue the the Open University London. Perhaps we can do something together with you and Technion and with Bernhard Seeger/U Marburg who is actually the German specialist in CEP in Germany
Post a Comment