[Reaction-tg] ruleCore beta is ready!

["Marco Seiriö @ ruleCore"]

Hello reaction rule experts!

I'm happy to, at last, announce that our reactive rule engine ruleCore is
available for beta testing for anyone interested. It is provided as a 
service
so it's easy to test. No installation, just send and receive events from
the ruleCore server. Everything is done using events so load your
favorite XML, XPath and XSLT tools and start testing ;)

I'd would be glad to get comments on how this fits into RuleML
reaction rule ideas, current and future.

Everything is declarative, completely event-driven and in XML
so we think it is a good start.

The full announcement is below.


cheers
/Marco



The ruleCore server is an event-driven complex situation detector 
provided as a service and aimed at providing reactive capabilities into 
any EDA and event driven SOA platform.

RuleCore uses an declarative approach to monitor and track entities. It 
monitors the progress of user defined situations for each entity and 
provides immediate notification when a situation is detected for a 
particular entity.

*The Short Version*

    *

      A server providing event driven immediate complex situation
      detection -- Tracks and detects situations.

    *

      Event I/O layer built on slightly extended Mule, users do
      everything using events.

    *

      Uses well known concepts like XML, XPath, XSLT and DOM.

    *

      Rules, event stream views, situations and actions can all be
      managed dynamically and their run-time state can be monitored.

    *

      Unordered events will be sorted and re-sequenced by ruleCore.
      Allowing for events sent by clients with unsynchronized clocks.

    *

      Rule state is persistent and crash resistant with automatic recovery.

    *

      Built for easy integration into event driven architectures and
      message based integration frameworks. Plays well with message
      brokers, ESBs and message queues like WebSphere MQ.

    *

      Will be available as a service hosted in our data center and
      accessed using a number of event transport protocols provided by Mule.



*The Long Version*


We use a concept of active rules (do not confuse with 
production/inference rules!) to track and detect situations. Our 
solution is completely event driven and designed for loosely coupled 
distributed environments. Think message brokers, asynchronous messaging, 
JMS, event-driven SOA and that kind of architectures.


A situation is a combination of events as they happen over time. 
Situations are detected by ruleCore immediately as they happen. A 
situation starts to develop when a special initiator event occurs. This 
event might, or might not, be the first event in a situation. As the 
situation develops, more and more events are added and at some point a 
triggering event can cause the situation to be detected. The triggering 
event contains a summary, created with XSLT from an virtual DOM, of the 
detected situation.


RuleCore uses a declarative approach to situation detection, thus no 
programming is required. Situations are declared using XML. We use XML 
as our external representation but there's nothing in the concepts that 
actually require XML as such. But using XML is very practical as you can 
use your favorite editors, libs and tools. We also use XML related 
standards like XML-Schema, DOM, XPath and XSLT.


In ruleCore we use a concept of tracked entities. It's common to create 
rules in a way that each rule instance tracks one entity. It is possible 
to query the engine in order receive an event with the current state of 
a rule instance, thus allowing you to keep track of a situation as it 
develops for a particular entity. Great for early warning applications.


While designing ruleCore a lot of effort has been put into creating good 
support for the temporal aspects of situation detection. Keeping track 
of a large number of situations as they develop, each consisting of 
multiple events with timing constraints, is pretty tricky using 
traditional tools such as databases or plain old code.


Although we use a rather strict and "pure" definition of events, see 
below, we are very pragmatic when it comes to event transport protocols. 
Basically anything that can carry a piece of XML in and out of ruleCore 
is okay. RuleCore uses an extended Mule ESB to implement its Event I/O 
layer. You can basically use any (30+) of the transports available for 
Mule or easily build your own ones. We have added some security, traffic 
logging, database driven configuration and event sequencing to the Mule 
we use.

A rule consists of three major parts. The view, the situation and the 
action. Rules are created and evaluated automatically in response to 
events.

The view declares which events are seen by each rule instance. The view 
is a peephole into the incoming event stream. The events in the view are 
normally semantically related. For example carrying information about 
the same server, person, area or process. The view gives each rule 
instance an unique context in which the situation detection is executed.

The situation describes a combination of events as seen in the view. If 
the correct combination of events are seen over time, the situation is 
detected. Very advanced situation declarations can be created by 
combining a number of situation detector nodes in a tree.

The action is used to report on a detected situation. An action creates 
a new event by executing an XSLT transformation on a virtual DOM 
document describing all the events used in the situation detection. The 
event created by the action is sent out from ruleCore on a outbound 
channel and is the way you know that a rule in ruleCore has triggered.


*Events -- The ruleCore Way*


There is unfortunately no common syntax or semantics for events in the 
Complex Event Processing (CEP) world. We have chosen a simple event 
model that we believe will be usable for most types of applications.

We see an event as a notification about state change in some entity.

In our model an event happens at an exact point in time and two events 
can not occur at the same point in time. If you think they do, your 
timer resolution is too low.

Events are immutable. Events can not be modified in any way after they 
are created. This makes sense as event are notifications about something 
that has already happened and something that has happened can't "unhappen".

All events have a globally unique ID. We use UUIDs so both event sources 
and ruleCore can create an event ID.

Each event has a timestamp. The event's timestamp tells when the state 
change occurred, not when the event was published or received.

Events are encoded in XML and have a header and a body.

    *

      The event header contains event meta-data such as security related
      information.

    *

      The event body is any valid XML fragment with additional detail
      about the state change.


Events can be generated by multiple sources with unsynchronized clocks. 
Events are (re)sequenced in ruleCore in order to create an ordered flow 
of events. The sequencer will sort late and early (timestamp in the 
future) events and create a (synthetic) ordering for events even if they 
have the same timestamp. Thus our rules will always operate on one 
single ordered stream of events.


*ruleCore as a Service*

Access to ruleCore will be provided as a service. The architecture of 
ruleCore is ideal for SaaS solutions as the user does everything by 
sending events to ruleCore and receives reaction events as response to a 
rule triggering. Monitoring of the engine is done using events too. The 
user submits an XPath query to the engine in order to query it's 
internal virtual DOM document which holds the complete state of the 
engine. The response to the query is sent back as an event.


A free subscription to the service can be created on our web page soon, 
meanwhile you need to contact us at support at rulecore.com 
<mailto:support at rulecore.com> if you like to test the beta service.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ruleml.org/pipermail/reaction-tg/attachments/20071127/879caddc/attachment.htm