Hello from Orlando, two out of the three days of the EPTS meeting is behind us, and there is half a day to go, before the start of the co-located Gartner Event Processing Summit.
I'll summarize the meeting some later this week (well, it should end before summarized). Just will report on two interesting insights. The first was made by Richard Tibbetts who talked about two types of event processing functionality: transformation and orchestration. This has some similarity to classification of rules to rules that create additional facts (derivation or inference) and behavioral rules that trigger actions (or prevent actions from happening). This classification is valid, and joins some other classifications made of event processing functionality.
The second insight, which will probably generate action item tomorrow in the EPTS closing meeting is "classification of applications". During the three EPTS meetings, the Dagstuhl seminar, and some other related work, we have collected a long list of use cases in many domains and types, and now we have enough sample to start analyzing them. What we'll probably need to do is to get back to all the presenters in all these events with a request to provide information using some templates, and then analyze the information and draw some conclusion about --- what event processing in reality is really is... stay tuned...
Other than that, good meetings - both inside and outside the regular sessions. Some newcomers, and most of the old players...
2 comments:
I'm don't agree that the classification is valid (at least the way it was described), and it's a point that was discussed at the time. It is not a good idea to classify the event processor according to the reaction to an emitted event - something that is outside of the control of the event processor.
Let's say that event processor A emits an event eA. Let's say that eA is consumed by event processor B, and that if B receives eA, it initiates a business process. So therefore it would be classified as orchestration. But if eA was consumed by a different event processor that didn't initiate a business process, then A is classified as a transformation event processor.
It would be a far better idea to classify event processor B according to the type of event processing it performs:
Manipulations (filter, tranform, enrich, etc - anything that changes the properties of an event)
Process (pattern detection, "window" calculations, track and trace)
React (initiate a business process, send an email, etc)
Comments?
Hi Brian. The classification is whether the event processing agent is deriving information or communicating with an external consumer (i.e. if it is a "leaf" in the network). This is not the most important classification, but it is a valid one.
Opher
Post a Comment