tag:blogger.com,1999:blog-7831813422886730737.post2600965241315516003..comments2023-10-08T10:44:28.524+03:00Comments on Event Processing Thinking: More on the structure of event representationOpher Etzionhttp://www.blogger.com/profile/10791357917675270335noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-7831813422886730737.post-39964826945663607152009-05-21T17:13:26.564+03:002009-05-21T17:13:26.564+03:00I am wondering about your use of the term header h...I am wondering about your use of the term header here. I think you are using this term to mean the fields that should be defined on every event, while the payload is the application specific part. <br /><br />This use of "header" has become popular, and for the most part, the conflicting meanings (which I'm getting to) are easily differentiated based on context. But since you are writing a reference book, I thought I'd bring this up.<br /><br />The word header implies that it is some kind of record that comes physically first in a message. Traditionally, the two uses for a header were to describe the parsing of the subsequent data (record length, record type, checksum, etc) or to describe some set of fields that could be parsed in order to route or otherwise process the message, without bothering to parse the underlying payload. For an example of the second type of header, a TCP packet has two headers: the IP header parsed by the routing infrastructure and the TCP header parsed by the protocol stack (although of course, these days plenty of modern network components parse both headers).<br /><br />At some point, messaging products like MQ series defined custom properties that could be added to the header of a bus message to facilitate handling of the message without parsing the payload. And because they were a structured way of passing around some convenient data, applications started using this kind of thing for properties that should probably have been included in the payload of the message instead (the payload should possibly have its own header that is separate from the MQ header). And after years of this use, the term header is used for fields that are common to all messages or that are application standard.<br /><br />But "header" is different from standard fields, which are not necessarily in a header. In practice, most experienced people would not be confused by this, but I wonder if junior practitioners reading about the topic for the first time might be.Hanshttps://www.blogger.com/profile/03057096345613832279noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-78077277652266143692009-05-18T23:59:00.000+03:002009-05-18T23:59:00.000+03:00Hi Marco. You, of course, can have a model in whic...Hi Marco. You, of course, can have a model in which event is classified to event type only in run-time, furthermore, different subscribers to the same event can classify it differently. It may be appropriate for applications whose main function is event dissemination. However, for different types of applications, it is easier to process if they are typed, and there is a possibility to create patterns/predicates based on attributes value. So there is a trade-off here. Most applications that I came across had events which are uniquely typed.<br /><br />cheers,<br /><br />OpherOpher Etzionhttps://www.blogger.com/profile/17070103285719046013noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-73709717320031628112009-05-18T11:02:00.000+03:002009-05-18T11:02:00.000+03:00If the information about semantics are attached to...If the information about semantics are attached to the event of its type, would it not be hard for different observers to assume a varying semantics when it comes to generalizations for example? <br /><br />Not sure if I think in the right way here, but I sometimes (I have not made up my mind of this one) think that it is the private information of the observer which decides how event instances and event types are related. <br /><br />Thus I would think It would be wise to decouple this information from the events.Mhttps://www.blogger.com/profile/15928652667178672308noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-79332917652222782182009-05-17T09:54:00.000+03:002009-05-17T09:54:00.000+03:00Hi Marco.
You are right, unlike the regular sema...Hi Marco. <br /><br />You are right, unlike the regular semantic data models in which generalization and specialization are absolute terms, in the case of events they may be conditioned based on context or any predicate, and may be asolute. This is still a property of event type, and is used to determined for which event instance how to classify for processing.<br /><br />cheers,<br /><br />OpherOpher Etzionhttps://www.blogger.com/profile/17070103285719046013noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-66302756229867113732009-05-17T09:48:00.000+03:002009-05-17T09:48:00.000+03:00Do you think that event relationships are a proper...Do you think that event relationships are a property of the events themselves or something that is decided by the one looking at the events?<br /><br />Could we have different relationships depending on the context the events are used in?<br /><br />For someone, one particular event might be a considered to be subclass of "warning" and for others it might be "fatal error", all depending on your perspective.Marco Seiriöhttp://www.rulecore.com/CEPblognoreply@blogger.com