You've seen that event-based systems differ markedly from request-based systems (see Table 6.1 for a summary). Event-based and request-based systems are duals of each other. Whereas the receipt of a request triggers the action of a request-response system, the receipt of an event triggers event-driven systems. The nature of an event is different from that of a request. A request says, "Do this for me." In contrast, an event says, "This happened." In a request-driven system, the sender chooses what action to take. In an event-driven system, the sender merely says that something happened. Event processors have no obligation to the endpoint. Endpoints are obligated to report events and respond to directives. Conversely, a client in a request-driven system has no obligation to the server. It can make a request or not. Servers are expected to fulfill requests.
*** [Table]
Table 6.1—Request-Based Versus Event-Based Systems
Request-BasedEvent-Based
SignalRequest receiptEvent receipt
Nature"Do this""Something happened"
ObligationAt serverAt endpoint (client)
InterpretationOn clientOn server
*** [END Table]
As discussed, event processors interpret what an event means. A request, on the other hand, implies that the interpretation[md]what should happen[md]has already occurred. You can think of this as receiver, instead of sender, determinism.
Because of these differences, the flow control of event-processing systems is very different from that of request-response systems. Consequently, applications are constructed differently in event-driven systems. The language at the heart of KEA, the Kinetic Rule Language, is optimized for building reactive, event-based applications.
Manage space
Manage content
Integrations