RE: Fitting PR and RR into logical rules

Sandro and all,

We will give an example of reaction rules that could be used in the
context of a prototype distributed application developed in Betfair. A
Manager node is responsible for holding housekeeping information about
various servers playing different roles. When a server fails to send a
heartbeat for a specified amount of time, the Manager assumes that the
server failed and cooperates with the Agent component running on an
unloaded node to resurrect it.

A typical rule for receiving and updating the latest heartbeat would
look like this.

rcvMsg(XID,Protocol,FromIP,inform,heartbeat(Role,RemoteTime)) :-
	time(LocalTime)
	update(heartbeats(FromIP,Role,RemoteTime,LocalTime)).

Note that the rule has inverted syntax with respect to your suggestion.
The actions (note the plural here) part is in fact the body of the rule.
The rule looks like a traditional derivation rule but is distinguished
from one by a special predicate name rcvMsg used in the head of the
rule. The rule responds to a message pattern matching the one specified
in the rcvMsg arguments. XID is the correlation-id of the incoming
message; inform is called a performative representing the semantic type
of the message, in this case, a one-way information passed between
parties; heartbeat(...) is the payload of the message. The body of the
rule enquires about the current local time and updates the record
containing the latest heartbeat from the controller. This rule follows a
push pattern where the event is pushed towards the rule systems and the
latter reacts.

The ECA rule shown below (it is distinguished by a special predicate
name eca) is a pull-based rule that is activated every second by the
rule engine and for each server that fails to have sent heartbeats
within the last second will detect server failure and respond to it by
initiating failover to the first available unloaded server. The
accompanying derivation rules detect and respond are used for specific
purpose of detecting the failure and organising the response.

eca(
	time( every('1S') ),
	event( detect(controller_failure(IP,Role,'1S')) ),
	action( respond(controller_failure(IP,Role,'1S')) )
).

detect(controller_failure(IP,Role,Timeout)) :-
	time(LocalTimeNow),
	heartbeats(IP,Role,RemoteTime,LocalTime),
	LocalTimeNow-LocalTime > Timeout.

respond(controller_failure(IP,Role,Timeout)) :-
	first(servers(status(Server,unloaded))),
	update(servers(status(Server,loading))),
	sendMsg(XID,loopback,self,initiate,failover(Role,IP,Server)).


As you can see, the logic involves possible backtracking so that all
failed components will be resurrected. The wisdom of this decision is
beside the point--this example is of course not used directly in
production.

If you look at the Prova presentation
(http://www.prova.ws/etc/ProvaPresentationMay2005.ppt) at the end it
gives examples of reaction rules directly comparable with state machines
or workflow languages.

In summary, the situation (complex event) detection process may be
complex and the reaction to it may be much more involved than just
having a single action. Yes, having one action is nice and clean but
this is not how things work in realistic event-response patterns as
opposed to simple examples.

Any comments/ideas/flame is welcome.

Alex

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Sandro Hawke
> Sent: 02 June 2006 15:36
> To: Francois Bry
> Cc: public-rif-wg@w3.org
> Subject: Re: Fitting PR and RR into logical rules
> 
> 
> 
> > Thinking of an interchange between deductive and production/eca
rules is
> > in my humble opinion naive because it raises extremely complicated
> issues
> > that are far from being solved and most probably never will be.
> >
> > Otherwise, one af the great dreams of software engineering would be
> > achieved: automatically generating a imperative program from a
> > declarative specification or vice versa.
> 
> I'm not suggesting building an automatic mechanism to tranform all PR
> rulesets into FO rulesets.  Rather I'm suggesting that if we look at
the
> use cases for PR we'll see that semantically they fit nicely in with
FO.
> 
> Specifically, here's my strawman.   I propose the ECA/Reaction rule:
> 
>     on Event
>     when Condition
>     then Action
> 
> be treated semantically as the Horn rule (FOL implication):
> 
>     if eventHappened(Event) and Condition
>     then actionRequested(Action)
> 
> and similarly for production rules (just drop the event part).
> 
> This does not mean that an FOL theorem prover would be an effective
way
> to execute real-world ECA rule sets, but it does mean that any results
> it was able to compute would be correct.  (That is, it supports the
> Soundness requirement I've been advocating.)  I do expect that some
easy
> ECA rulesets would work with resolution-style reasoners using this
> approach, but that's more a confirmation than a goal.  (This proposal
> does not address the split in semantics between LP and FOL - that's a
> separate question.)
> 
> If you want to argue against this proposal, please just point to rules
> from our use cases for which you think this approach will be bad and
we
> can look at an implementation sketch in detail.
> 
>      -- Sandro
> 
> 
>
________________________________________________________________________
> In order to protect our email recipients, Betfair use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
> 
>
________________________________________________________________________

Received on Friday, 2 June 2006 15:22:23 UTC