Hello - again in a business trip after some break in trips - now in Regensburg, Germany (see in the picture) for the CITT conference that starts tomorrow, so I'll have time to write about it later this week. The topic of this posting relates to the event processing conceptual model and deals with the producer side.
Getting events from a producer may be the most time-consuming work in the event processing application, depending on number of producers, existance of adapters, and complexity of instrumentation (if needed)
A producer can be either a sensor that reports on an event it senses, or a creator of an event, in which case the event is typically an instrumentation of something that happens within the producer.
While "event-driven" is closely associated with the push mode - meaning the consumer decided when and how it sends events, this is only one of the possible modes. In some cases "pull" mode is used - meaning the event processing networks pulls events from the producer.
Why is pull needed? several reasons:
(1). Not all the sources are really producers -- the source may be a piece of legacy software that has not been designed to produce events.
(2). Push may not be cost-effective - we have to weigh the benefit of processing events fast, and the overhead occurs in transaction systems to obtain the events. This depends on the application, on type of processing for events and the tolernace of the operational system.
Pull can be done as: periodic pull or on-demand pull. More about the conceptual model parts - later.
No comments:
Post a Comment