The first draft of the new version documentation is now available at http://www.prova.ws/documentation.php. The current focus is on running Prova from command line and Java, reactive messaging and event processing.
A New Year 2010 is a great time to go ahead with a final push for a full Prova re-release with Documentation now in position one in the queue. The home for the documentation is the Confluence WIKI pages. The most overdue are the areas on Reactive messaging and Event processing.
Prova JIRA at http://www.prova.ws/jira is now upgraded to the JIRA Enterprise version. Special thanks go to Atlassian who kindly donate their excellent products to Open Source projects. Prova JIRA is now correctly linked to the Prova Subversion repository in SourceForge. JIRA plugin for Mylyn in Eclipse is now used for tracking issues and task assignment, which is in line with how we do things in Betfair for research projects.
This post discusses some arguments in favour of joining together the workflow logic with event processing. Typically, event processors and, in particular, stream processors detect event patterns, i.e., groups of events related by temporal relationships and meeting constraints on their content. Event detection is usually an all-or-nothing affair, so that a composite event is either detected or not, in which case nothing happens.
This post gives more details on the approach to event patterns now being added to the new Prova version. As explained in the previous article, the main idea is to group event reactions and associate an operator to the group. I use a term event channel to refer to each reaction that is a member of a reaction group. The new version introduces a variety of annotations that fine-tune the semantics of a reaction group. We make a distinction between control channels and ordinary signal channels.
Event algebras are a formalism for describing composite events that are groups of other events satisfying specified algebraic constraints. We wish to embed event algebra into the Prova language in the simplest, most natural way, allowing Prova rulebases to detect situations arising from events arriving according to pre-defined temporal patterns.
This post is updated according to a revised approach to event algebra. More details will be given shortly. Beginning where the previous article left off, let's look at an example that shows reaction groups including reactions that form a sequence, rather than are active at the same time. In fact, there is no need to use anyhing else but AND-groups introduced in the previous post.
This post is updated according to a revised approach to event algebra. More details will be given shortly. The previous article http://prova.ws/csp/node/20 described the use of the @timeout annotation for imposing a time constraint on arrival of messages. This allows sequential event patterns to be defined quite easily. A further extension of this idea is to use annotations to group reactions. This post describes one such annotation that we call an OR-group (defined using the @or operator annotation).
Annotations and guards are useful for any general purpose rules. Messaging and reaction rules are no exception. rules/reloaded/guard.prova now contains an additional example that shows how annotations and guards can be used to detect sequential event patterns. First, let's look at the client.
:- eval(client()). client() :- % Send all the test messages from a separate thread switch_thread(), sendMsg(XID,task,0,request,login(user1,'10.10.10.10')), % Wait synchronously, could have waited asynchronously instead java.lang.Thread.sleep(500L),
The new update implements Prova guards on literals. Let's start with an example. Imagine that during unification, the target rule matches the source literal but we do not want to proceed with further evaluation unless a "guard" condition evaluates to true. The guards are specified in a syntax that is similar to the one used in Erlang (using brackets instead of the 'when' keyword) but the semantics are more appropriate for a rule language like Prova. See rules/reloaded/guard.prova and ProvaMetadataTest.java.
@author(dev1) r1(X):-q(X). @author(dev22) r2(X):-q(X).