AW: [Reaction-tg] ruleCore beta is ready!

Tue Nov 27 20:24:19 AST 2007

Hi Marco,

Since I’m currently attending a REWERSE meeting a quick answer:

RuleCore will definitely fit into the ideas and works in Reaction RuleML.
You might take a look at Rule Responder (http://responder.ruleml.org/ ) which seems to have overlaps and uses similar techniques as ruleCore such as an Enterprise Service Bus and event messages.

An idea would be to work on joint use cases where ruleCore becomes one rule engine in Rule Responder and communicates with the other platform-specific rule engines such as Prova, OO-jDrew,… using Reaction RuleML as common rule interchange format. The integration should be easy given that Rule Responder deploys rule engines as distributed web-based service, supports arbitrary transport protocols via the ESB and uses Reaction RuleML event messages to interchange queries and answers or complete rule sets. So, we just would need to work on a translator from your ruleCore language into Reaction RuleML.

Maybe the best way to start our collaboration would be that you give a presentation about ruleCore in one of our next Reaction RuleML technical telephone conferences? If you agree I will look for an empty slot in the next weeks.

Below you will find more information about Rule Responder.

Best,

Adrian

The Rule Responder architecture consists of four essential parts:

1. RuleML / Reaction RuleML as common platform-independent (PIM layer) rule / message interchange format:

http://ibis.in.tum.de/research/ReactionRuleML/
http://www.ruleml.org/

2. Prova as a rule-based message / process flow engine used to describe and execute in a declarative rule-based way the flow of inbound/outbound messages between rule inference endpoints (arbitrary rule engines / inference services) 

http://www.prova.ws/

3. The Rule Responder middleware with an integrated enterprise service bus used as communication middleware to transport messages over 30 different transport protocols (such as JMS, HTTP, SOAP) and as Web-based object-broker to install distributed inference services (rule engines).

http://responder.ruleml.org/

4. Arbitrary platform-specific rule engines (e.g. OO-jDrew, Prova etc.) (PSM layer) deployed as inference services on the ESB to answer queries and execute rules wrt to the local rule bases of the rule engines.

To learn more about the general ideas and goals of Rule Responder as Pragmatic Agent/Service web on top of the Semantic Web see e.g.:

Paschke, A., Boley, H., Kozlenkov. A, Craig, B.: Rule Responder:
RuleML-Based Agents for Distributed Collaboration on the Pragmatic Web, 2nd Internation Conference on the Pragmatic Web, Tilburg, Netherlands, October, 2007.
http://www.slideshare.net/pragmaticweb/icpw2007paschke
http://oro.open.ac.uk/9275/

To learn more about the use of Reaction RuleML and the technical implementation see, e.g.
http://ibis.in.tum.de/research/ReactionRuleML/docs/vldb_eda-ps07.pdf

Use Cases see e.g.:

Health Care and Life Science:
Paschke, A.: Prova - A Distributed Semantic Web Rule Engine, W3C HCLS Telecon Presentation, October, 15th, Telecon, 2007.
http://ibis.in.tum.de/projects/paw/docs/HCLS_2007.pdf
http://ibis.in.tum.de/projects/paw/hcls/

Virtual Organizations and Expert Finder:
Boley, H., Paschke, A.: Expert Querying and Redirection with Rule Responder, 2nd International ExpertFinder Workshop: FEWS2007 (Finding Experts on the Web with Semantics), Busan, Korea, November 2007.
http://ibis.in.tum.de/projects/paw/ruleml-2007/
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-290/paper0
1.pdf

Distributed Grid Inductive Logic Programming 
Paschke, A., Schröder, M.: Inductive Logic Programming for Bio-Informatics in Prova, VLDB 2007 Workshop on Data Mining on Bioinformatics, Vienna, Austria, September, 2007 http://bio.informatics.indiana.edu/VLDB07/finalprogram/paschke-adrian.pdf
http://ibis.in.tum.de/projects/paw/ilp/

Complex Event Processing and Business Activity Monitoring:
Paschke, A.: "RuleML and Reaction RuleML as a Quasi Standard for Rule Interchange– Standardization in the Area of Rules and CEP", 5th "Meet the Experts – CEP, BPM, BAM, SOA, EDA", Regensburg, June, 2007 
http://www.citt-online.com/downloads/exp5/RuleML_Experten_Treffen_Regensburg
2007.pdf

Rule Based Service Level Agreements
http://ibis.in.tum.de/projects/rbsla/index.php 

________________________________________
Von: reaction-tg-bounces at ruleml.org [mailto:reaction-tg-bounces at ruleml.org] Im Auftrag von "Marco Seiriö @ ruleCore"
Gesendet: Dienstag, 27. November 2007 17:46
An: reaction-tg at ruleml.org
Betreff: [Reaction-tg] ruleCore beta is ready!

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 if you like to test the beta service.

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail