W3C home > Mailing lists > Public > public-rif-wg@w3.org > September 2008

Re: Congratulations on Christian's and co. courage

From: Ed Barkmeyer <edbark@nist.gov>
Date: Wed, 03 Sep 2008 18:41:30 -0400
Message-ID: <48BF129A.9020108@nist.gov>
To: Paul Vincent <pvincent@tibco.com>
CC: public-rif-wg@w3.org

Paul Vincent wrote:

> 1. Gary is correct from the logical perspective, of course.
> 
> 2. Events can be duplicates either in their transmission or their
> meaning:
> 
> In middleware terms, it is normally the responsibility of the middleware
> to ensure duplicates don't happen! 
> 
> In event terms, though, I can receive multiple events which signify the
> same information. For example I may be polling a hardware device and
> getting the same result, or someone may hit the "Buy" button in their
> web browser twice. 

The general problem which Paul here addresses is the distinction between 
"hardware/software" events and "business" events.  A business event is 
an occurrence in the world that has some semantic interpretation 
relative to the goals of some activity.  A hardware/software event is an 
observed change of state in a technical element.  In general, relating 
the latter to the former requires a combination of conventions and rules.

For example, if you get an order (message) from a trading partner, you 
act on it.  But if you and your trading partner have somewhat 
unpredictable communications paths that may result in duplicate 
messages, you agree to label each transaction with a transaction number. 
  That is the convention, and then the recipient has a rule that 
discards any transaction whose number has already been seen.  (At a 
lower level of middleware communication, this pattern is a required 
behavior in the proper implementation of certain protocols, e.g., TCP, 
because the protocol requires the sender to re-send the message if it is 
not acknowledged within a certain length of time.)

What Paul suggests is a heuristic rule for handling a phenomenon that 
was called "stutter" or "bounce" in the signaling systems of the 1970s:

> In the latter case, there are 2 order events but they represent the same
> order, so there might be some rules / logic in the system to handle this
> (de-dupe). Those rules could presumably be represented in RIF, e.g.
> 
> If ?BetA and ?BetB occur within 5 secs of each other AND sameContent(
> ?BetA, ?BetB)
> Then // assume BetB is a dupe
> ?BetB.dupe = TRUE, ?BetB.IsDupeOf = ?BetA, ?BetB.Status = invalid.

This sort of example is not really a CEP issue -- it is about extracting 
meaningful events from curious technical behaviors.

OTOH, one can have a confluence of truly distinct technical events, all 
of which denote a single business event, and that is a CEP concern.  My 
favorite example is the sequence of status reports from a manufacturing 
workstation:
  1 - Process X step 7 in progress, machine state operating, workpiece 
state normal, heat sensor 3 in yellow zone
  2 - Process X step 7 control error, machine state recovering, 
workpiece state normal, heat sensor 3 in red zone, heat sensor 4 in 
yellow zone
  3 - Process X step 7 unrecoverable error, machine state going safe, 
workpiece state unknown, heat sensor 3 no data, heat sensor 4 in red zone
  4 - Process X aborting at step 7, machine state safe, workpiece state 
unknown, heat sensors 3 and 4 no data, operator intervention required.

The business event can be summarized as: "there is a fire in the 
workstation".

[BTW, the black box data for the last 2 minutes of the shuttle flight 
that burned up on re-entry shows a similar pattern of status reports, as 
right wing sensors one by one report problems before going silent.]

But there won't really be executable rules for that; the applicable 
business rules will involve operators and fire extinguishers.  What you 
do see in the above is a sequence of low-level rules firing recovery 
activities, or handing off to the next level up when the situation is 
out of their control.

The relationship between rules, actions, events and CEP is intimate and 
complex.  The job of this group is only to deal with the rule 
representation concerns.  All the actions and events are external 
predicates, and all the lore that goes with them is way beyond the scope 
of RIF.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."
Received on Wednesday, 3 September 2008 22:42:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:54 GMT