- From: Alex Kozlenkov <alex.kozlenkov@betfair.com>
- Date: Tue, 21 Nov 2006 21:26:55 -0000
- To: "Paul Vincent" <pvincent@tibco.com>
- Cc: <public-rif-wg@w3.org>
Paul, We should probably address the subject in more detail outside of this public discussion. At the moment, let's say ECA are definitely on the RIF table but the exact scope is yet to be determined and the only matter to be discussed now are the discriminators. I would not claim a full CEP model is what we are looking for but have a look at the Reaction RuleML and REWERSE r3 links I had sent before. These go beyond basic ECA but are not necessarily into CEP proper. RIF might end up having something in between. Cheers, Alex >> -----Original Message----- >> From: Paul Vincent [mailto:pvincent@tibco.com] >> Sent: 21 November 2006 17:43 >> To: Alex Kozlenkov >> Cc: public-rif-wg@w3.org >> Subject: RE: [RIFRAF] Response to ACTION-179 --> CEP discussion >> >> Hi Alex: >> >> Your counterexample is the http://www.w3.org/2005/rules/wg/wiki/Rule- >> based_User_Notification_%28RUN%29_framework use case, referencing the >> Prova rule system - http://www.prova.ws/ . >> >> In terms of RIF and CEP, I can only say that the TIBCO CEP product uses BOTH >> a state transition diagram AND ECA rules to represent CEP. Other vendors >> provide stream-processing SQL-type languages. The CEP vendor community >> (see http://www.complexevents.com/ ) is currently looking at the possibility of >> standards, but as this is a "new market area" [although of course CEP has been >> done using rules for a long time] the current opinion seems to be quite cool on >> the idea. See other posts on the topic in >> http://tech.groups.yahoo.com/group/CEP-Interest/ and messages such as >> http://tech.groups.yahoo.com/group/CEP-Interest/message/631 >> http://tech.groups.yahoo.com/group/CEP-Interest/message/800 >> etc >> >> I would be wary of suggesting the RIF can handle CEP (beyond ECA) as this >> implies to me event modelling/representation. But I may be wrong and maybe >> there is a common (ie supported by >1 system type) event language / XML >> representation / RDF mapping that already exists to support this? For >> conventional production rules the data model is quite simple, and the only event >> to consider is the service invocation event which is implied by the >> ruleset/rulesets' identifier (ie rule service). >> >> I would also be wary of promoting RIF for CEP without support from the wider >> vendor community in this area. >> >> Cheers >> >> Paul Vincent >> TIBCO - ETG/Business Rules >> >> >> >> -----Original Message----- >> From: Alex Kozlenkov [mailto:alex.kozlenkov@betfair.com] >> Sent: 21 November 2006 16:50 >> To: Paul Vincent >> Cc: public-rif-wg@w3.org >> Subject: RE: [RIFRAF] Response to ACTION-179 >> >> Paul, >> >> >> And: in terms of rule classifications/ontologies, the ECA rules used >> in TIBCO are >> >> in effect a specialization of PRR. As event mechanisms can be >> considered out of >> >> scope for RIF (in my opinion, as both the CEP world and >> organizations like OMG >> >> SOA are in the early stages of investigating this as I understand), >> full CEP rules >> >> are unlikely to be an early candidate for RIF interchange. >> >> Respectfully, I do not agree with your point. While CEP is out of scope >> of PRR, it is not out of scope of RIF. Event processing IMO could be >> captured quite nicely by compact self-contained syntax and semantics and >> we do have use cases, although they are not part of the official 10 >> list. For us as a company, it is critical to have this standard. >> >> Alex >> >> >> >> -----Original Message----- >> >> From: Paul Vincent [mailto:pvincent@tibco.com] >> >> Sent: 21 November 2006 16:33 >> >> To: Alex Kozlenkov; Paula-Lavinia Patranjan; Leora Morgenstern >> >> Cc: public-rif-wg@w3.org >> >> Subject: RE: [RIFRAF] Response to ACTION-179 >> >> >> >> This raises an interesting point: semantics vs syntax of target rule >> systems as >> >> far as RIF is concerned. >> >> >> >> TIBCO's BusinessEvents is one of the more successful commercial CEP >> (Complex >> >> Event Processing) systems & uses a type of "ECA" rules, but rules >> are defined in >> >> terms of production rules (plus a state transition diagram). So in >> terms of >> >> representation (and interchange formats), production rules are >> sufficient for the >> >> rules, but not for the full semantics of CEP. Indeed, the execution >> semantics are >> >> slightly different from (ie an event-driven superset of) >> conventional Rete-based >> >> rule engines (ie PRR). >> >> >> >> So: Business Events rule language ~= PRR + event semantics >> >> >> >> And: in terms of rule classifications/ontologies, the ECA rules used >> in TIBCO are >> >> in effect a specialization of PRR. As event mechanisms can be >> considered out of >> >> scope for RIF (in my opinion, as both the CEP world and >> organizations like OMG >> >> SOA are in the early stages of investigating this as I understand), >> full CEP rules >> >> are unlikely to be an early candidate for RIF interchange. >> >> >> >> Real world: supporting business rules (eg as supported in RIF/PRR >> format) >> >> *are* used to support CEP event rules, and are definitely a >> candidate for >> >> interchange to this CEP system. >> >> >> >> Summary(theory): many ECA rules may be considered derivatives / >> >> specializations of production rules, with different semantics (ie >> event processing >> >> conditions and actions). For representation, they will be covered by >> the >> >> production rule representation extended to handle popular event >> tests and >> >> actions. However, as RIF will not encode event persistence data, the >> utility of >> >> RIF for some ECA systems (such as CEP) will be limited. Note there >> are no CEP >> >> use cases. >> >> >> >> Paul Vincent >> >> TIBCO - ETG/Business Rules >> >> >> >> >> >> -----Original Message----- >> >> From: public-rif-wg-request@w3.org >> [mailto:public-rif-wg-request@w3.org] On >> >> Behalf Of Alex Kozlenkov >> >> Sent: 21 November 2006 15:11 >> >> To: Paula-Lavinia Patranjan; Leora Morgenstern >> >> Cc: public-rif-wg@w3.org >> >> Subject: RE: [RIFRAF] Response to ACTION-179 >> >> >> >> >> >> Guys, >> >> >> >> For reaction rules, there are two ongoing projects that could >> provide >> >> ideas for ontology characterization. >> >> >> >> One is the Reaction RuleML initiative: >> >> http://ibis.in.tum.de/research/ReactionRuleML/ . >> >> >> >> The other is REWERSE r3 prototype: >> >> http://rewerse.net/I5/r3/. >> >> >> >> In the first one, we have distinguished active vs. passive reaction >> >> rules (essentially having to poll vs. reacting passively to pushed >> >> inbound messages) functionality. We also orthogonally distinguish >> global >> >> (non-contextual) and local (contextual) rules. In particular, the >> latter >> >> allow the reactions to be contextualized by the current evolving >> state >> >> of conversations making them comparable to process algebras, in >> >> particular, pi-calculus. >> >> >> >> Passive rules could be also categorized as message-based in that >> they >> >> effectively capture communication acts explicitly. >> >> >> >> The REWERSE r3 prototype, also using the Prova language for the >> >> conditions and actions part, is based on a developed r3-ontology. It >> >> specifically distinguishes query and test components of an ECA rule. >> >> >> >> In summary, these are the resources that perhaps we should consider >> >> aligning the current RIFRAF view of the ECA area with. >> >> >> >> Alex Kozlenkov >> >> Betfair Ltd. >> >> >> >> >> -----Original Message----- >> >> >> From: public-rif-wg-request@w3.org >> >> [mailto:public-rif-wg-request@w3.org] On >> >> >> Behalf Of Paula-Lavinia Patranjan >> >> >> Sent: 21 November 2006 12:28 >> >> >> To: Leora Morgenstern >> >> >> Cc: public-rif-wg@w3.org >> >> >> Subject: [RIFRAF] Response to ACTION-179 >> >> >> >> >> >> Hi Leora, >> >> >> >> >> >> This message is a response to the action we both took during the >> F2F >> >> >> meeting in Athens to revise and ontologize section 5 of RIFRAF >> (see >> >> [1] >> >> >> for my action). I read the comments attached to the answers to >> >> section >> >> >> 5's questions and tried to determine whether new questions >> should be >> >> >> added to this section or refinements of the existing questions >> are >> >> >> desired. Below are some proposals for improving section 5 of the >> >> >> questionnaire. >> >> >> >> >> >> (New discriminator to be added to 5.1) >> >> >> What kind of rules are used for realizing the reactive >> behaviour? >> >> >> * Event-Condition-Action (ECA) rules >> >> >> * Event-Condition-Action-Postcondition (ECAP) rules >> >> >> * Production rules >> >> >> * Other (Please specify!) >> >> >> >> >> >> (Update of discriminator 5.1.2; add the possibility to answer >> with >> >> >> 'Mixed' to the question) >> >> >> Are the different parts of a rule (e.g. Event, Condition, Action >> >> parts >> >> >> for a ECA rule) clearly separated (separation of concerns)? >> >> >> * Yes >> >> >> * No >> >> >> * Mixed (some rules in the language follow such a separation >> of >> >> >> concerns, some not) >> >> >> >> >> >> The comments to the question 5.2.3 'Does the language support >> only >> >> >> atomic events or also composite events (combinations of more >> than >> >> one >> >> >> event such as temporal or events)?' could be considered as basis >> for >> >> a >> >> >> new discriminator for the (concrete) types of composite events >> >> >> supported. The problem is that there are two many possibilities >> for >> >> such >> >> >> concrete composite events supported by a reactive language. >> >> Moreover, >> >> >> the questionnaire already contains similar discriminators but >> more >> >> >> abstract (see 5.2.6 and 5.2.7). Thus, I propose not to add a new >> >> >> discriminator for types of composite events. >> >> >> >> >> >> What is your opinion on the proposals above? >> >> >> >> >> >> Best regards from Munich, >> >> >> Paula >> >> >> >> >> >> [1] http://www.w3.org/2005/rules/wg/track/actions/179 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _________________________________________________________________ >> >> >> _______ >> >> >> In order to protect our email recipients, Betfair use SkyScan >> from >> >> >> MessageLabs to scan all Incoming and Outgoing mail for viruses. >> >> >> >> >> >> >> >> >> _________________________________________________________________ >> >> >> _______ >> >> >> >> >> >> >> >> >> _________________________________________________________________ >> >> _______ >> >> In order to protect our email recipients, Betfair use SkyScan from >> >> MessageLabs to scan all Incoming and Outgoing mail for viruses. >> >> >> >> >> _________________________________________________________________ >> >> _______ >> >> >> _________________________________________________________________ >> _______ >> In order to protect our email recipients, Betfair use SkyScan from >> MessageLabs to scan all Incoming and Outgoing mail for viruses. >> >> _________________________________________________________________ >> _______
Received on Tuesday, 21 November 2006 21:27:11 UTC