CEP applications often refer to specific time points or intervals on the time axis in order to perform certain actions or as part or complex event queries. Our stock market application might want to
perform a specific action every day at 4pm such as sending a message to all customers to remind them that the market will close in an hour. It also might have complex event queries that will determine the average price of a stock over a trading day. Time points such as “every day at 4pm” and time intervals such as “trading day” are usually not represented as messages in the incoming event stream. Still, one needs the ability to query such timer events.
XChangeEQ supports queries for timer events in a manner that is syntactically similar to queries against event messages. One can distinguish absolute and relative timer events. Absolute timer events are time points or intervals defined without reference to the occurrence time of some other event. They can be periodic, i.e., a sequence of time points or intervals as in “every day at 4pm.” Relative timer events in contrast are defined dependent on some other event. Relative timer events will be discussed in Section 6.7.
Example Queries to absolute timer events are specified just like queries to event messages. In fact, one can imagine querying timer events as querying a “virtual” stream of event messages that represent all possible time points and intervals. XChangeEQ offers one built-in way for specifying absolute timer events. The “virtual message” for this built-in absolute timer event has the root element timer:datetime and children to specify the time and data of the timer event. For example, the following query would set off a timer at 14:35h on July 31, 2008:
event i : t i m e r : d a t e t i m e {{ t i m e { " 1 4 : 3 5 " } , d a t a { " 2 0 0 8 - 0 7 - 3 1 " } }}
Queries for absolute timer events can also specify periodic timers. For example, the following query would set off a timer event at 16:00h (i.e., 4pm) on every day. A string representing the particular date will be bound to the variableD, which would be useful for example to include the data into a message that is generated from this event query.
event i : t i m e r : d a t e t i m e {{ t i m e { " 1 6 : 0 0 " } , d a t a { var D } }}
Issues related to time and calendars are often difficult since they might be specific to culture or application domain. For example, a stock market application might have the concept of a trading day, which would be the time interval from 9am to 5pm on every day except Saturdays, Sundays, and local bank holidays. XChangeEQdoes not aim at providing a complete solution to these issues within the event query language. Rather it allows to embed external calendars. These might be specified using a calendar system such as CaTTS [BRS05] or just programmed manually. The external calendar system basically has to generate an appropriate stream of messages from the timer specification. For example, the following event query could set off a timer event for trading days that might be specified in CaTTS. The variableD is bound to the day of the week.
c a t t s : t r a d i n g D a y {{ d a y O f W e e k { var D } }}
Built-in timer events The built-in timer of XChangeEQ is modeled after theCalenderclass of Java [Sun06]; objects of this class represent a specific date.2 Figure 6.2 shows an example of the virtual message for the timer at 14:35h on July 31, 2008 in Central European Summer Time (CEST).
2The class name “Calender” in Java is arguably a bit of a misnomer since its objects represent specific dates according to a calendar system (e.g., Gregorian) and time locales (e.g., time zone), not a calendar system in itself. However, by the time the Calender class has been introduced in Java, there already was a Date class, which represents dates according to Coordinated Universal Time (UTC).
t i m e r : d a t e t i m e { y e a r { 2 0 0 8 } , m o n t h { " J u l y " } , day - of - m o n t h { 31 } , hour - of - day { 14 } , m i n u t e { 35 } , s e c o n d { 0 } , m i l l i s e c o n d { 0 } , week - of - y e a r { 31 } , week - of - m o n t h { 5 } , day - of - y e a r { 213 } , day - of - w e e k { " T h u r s d a y " } , day - of - week - in - m o n t h { 5 } , am - pm { " pm " } , h o u r { 2 } , zone - o f f s e t { 1 } , dst - o f f s e t { 1 } , d a t e { " 2 0 0 8 - 0 7 - 3 1 " } , t i m e { " 1 4 : 3 5 " } , }
Figure 6.2: Example of built-in timer message for 14:35h on July 31, 2008 CEST
The multitude of fields in the timer message is necessary to allow for flexible specifications of periodic timer events. For example a query that sets off a timer at 9:00h on every second Tuesday of the month might be specified as:
event i : t i m e r : d a t e t i m e {{ day - of - w e e k { " T u e s d a y " } , day - of - week - in - m o n t h { 2 } , t i m e { " 9 : 0 0 " }
}}
It is possible to write timer event queries that do not make sense because they specify impossible dates. In this case, an XChangeEQ implementation might refuse to run programs containing such queries or issue a warning. The following are two examples of such timer queries, because there is no February 29, 2100 and because December 24, 2008 is a Wednesday not a Thursday.
event i : t i m e r : d a t e t i m e {{ d a t e { " 2 1 0 0 - 0 2 - 2 9 " } , t i m e { " 1 2 : 0 0 " } }} event i : t i m e r : d a t e t i m e {{ d a t a { " 2 0 0 8 - 1 2 - 2 4 " } , day - of - w e e k { " T h u r s d a y " } }}
External calendars Absolute timer events that are defined in external calendar systems are rec- ognized by XChangeEQaccording to the namespace of the root element. In ourcatts:trading-day example from earlier, the namespace prefix catts has to be bound to a namespace URI that is associated in the XChangeEQ implementation with an external calendar.
External calendars must generate a sequence of messages together with associated occurrence times from the timer specification (i.e., the query term). Because the sequence may be infinite, it must be provided to XChangeEQin an iterator style interface. The order of the iteration must be ascending according to the ending time. External calendar can thus be understood as a function c : N → M ×T×T (M the set of all data terms/event messages, T×T the set of all time intervals) withend(t(i)≤end(t(i+ 1)) for alli∈N. To eliminate possibilities of race conditions, XChangeEQ is then responsible for actually generating events out of the messages (i.e., initiating a query evaluation step at the ending time associated with the timer message).