At moment, use cases are developed that aim at showing to which extent the reactive language XChange is suitable for implementingbusiness rules. The business rules approach has been employed with success in the industry for describing the business logic; thus, their practicability has been already proven.
CHAPTER 6. USE CASES assert business structure or to control or influence the behaviour of the business”. (Business Rules Group3)
For example, “an order with value greater than 500 Euro has no delivery charge” is a business rule. Focus of the XChange use cases is the implementation of business rules and not their specification e.g. as a controlled English language or the validation of sets of business rules. However, not all business rules can be implemented; for example, “everyone in a construction area must wear safety helmet” can not be implemented by using programming languages. Though, the first given example of a business rule can be implemented (e.g. by using XChange as programming language).
Multiple classifications of business rules exist; the Rule Markup (RuleML) Initiative4considers three
kinds of business rules: integrity constraints,derivation rules(also called deductive rules), andreaction rules(also called reactive rules). Integrity constraints can be implemented for example by means of schema languages or can be enforced by means of reactive rules. The fact that the language XChange has reactive rules (i.e. XChange event-raising rules and transaction rules)anddeductive rules (i.e. Xcerpt rules) give reasons to claim that XChange is suitable for implementing (most kinds of) business rules. The developed use cases will bear evidence of this and/or will reveal useful extensions to XChange.
The EU-Rent5case study has been chosen for developing (some of the) XChange use cases; it is a case
study used by the business rules community to demonstrate their product abilities. EU-Rent is a (fictive) car rental company with branches in different cities and countries. XChange use cases consider Web-based EU-Rent branches distributed over the network. EU-Rent branches offer typical car rental services such as car reservations (rentals made in advance) or ’walk-in’ rentals, rentals of cars from different car groups are possible, and customers may return cars to different branches. Business rules used by the EU-Rent branches for constraining or controlling (some of their) processes (actions that might be part of workflows) regard e.g. car reservations, offered discounts, or car assignment. Some concrete examples follow:
(i) If the customer requesting a car rental has no valid driver licence, the request should be denied. (ii) If the car model requested for reservation is not available, a car of the same group should be assigned.
For flexible changes to business rule and processes, business rules should be separated from the pro- cesses, not contained in them; however, different implementation approaches are conceivable. In general, the approach chosen depends on the intended applications; for example, for the EU-Rent case study, busi- ness rules could be stored at each branch or just at the central branch(es) coordinating (local) ones. More- over, different approaches for so-calleddecision points(between steps of a workflow when a decision is to be taken based on the set of employed business rules) are possible. For example, business rules can be “verified” before executing each action (or process) of the workflow, or business rules can be “verified” when events occur during workflow execution.
The EU-Rent case study, as a concrete example where business rules and reactivity on the Web are employed, and the implementation in XChange of (some of) the possible scenarios are ongoing work. Inna Romanenko investigates this issues as her master thesis under the double supervision of Prof. Dr. Franc¸ois Bry and the author. This work has begun recently, but first results are promising. The EU-Rent scenarios can be combined withTravel organisationscenarios so as to support the travel organisation task with the possibility of renting cars for the trips; this is one of the possible directions for future work.
3Business Rules Group,http://www.businessrulesgroup.org/brghome.html 4RuleML,http://www.ruleml.org
5EU-Rent,http://www.eurobizrules.org/eurentcs/eurent.html
Part III
Conclusion
CHAPTER
SEVEN
Conclusion
7.1 Contributions
The research topic investigated by this thesis isreactivity on the Web. Identifying possible approaches to reactivity on the Web calls for analysing the characteristics of the Web – as environment for applications that exhibit reactive behaviour – so as to suit the reactive technology to them. Turning then to what re- activity means and keeping in mind that the environment is a distributed one, reactive technologies call for: updating data on the Web, exchanging information about events (such as executed updates) between reactive Web systems, and automatically reacting to combinations of such events. Moreover, of crucial im- portance for the Web (and also for the Semantic Web) is the lightness of technologies’ usage (in particular the languages’ usage) that should be approachable also by non-programmers.
Following a declarative approach to reactivity on the Web, a novelreactive languagecalledXChangeis proposed. XChange is a high-level programming language that offers means for programming distributed Web applications requiring state changes as reaction to events that have occurred on the Web. It consists of three components: an event query language, a Web query language, and an update language. XChange has an imperative nature, but its components do follow a declarative approach: The event query language of XChange offers means for declaratively specifying classes of events of interest that might require a reaction. The Web query language of XChange is inherited from the declarative Web and Semantic Web query language Xcerpt, i.e. the ’condition part’ of XChange reactive rules are Xcerpt queries and Xcerpt (construct-query) rules can be specified in an XChange program for constructing views over Web data. The update language of XChange offers means for declaratively specifying templates for the data before the updates, and templates for the data to be inserted, removed, or replaced. Though, an update language with explicit update operations (expressing e.g.do an insert) can not be fully declarative; also, a conjunction of updates to be executed in sequence has an imperative touch.
The research work presented in this thesis (having as materialisation the reactive language XChange) contributes to the research on (Semantic) Web reactivity with the following:
Recognised Requirements for Web Reactivity The development of application scenarios for reactivity on the Web has raised requirements for languages aimed at entailing enhancements of the actual Web with reactive capabilities. To mention some of these requirements: composite event queries and composite event detection, and event-driven transactions are between the first-class citizen of needed language abilities. However, different classes of applications exist that might be useful for upcoming, reactive Web systems; these share with applications like the ones presented in Section 1.2 and Chapter 6 some capabilities but, at the same time, might require new ones or just adapting the presented approach to the considered application domain.
Concept Clarification This thesis offers clear definitions and descriptions of the concepts and notions used by/in XChange for programming reactive applications. Most proposals for reactivity use notions that
7.1. CONTRIBUTIONS
do not always have an unambiguous meaning; overloading notions (for example, by not differentiating betweeneventandevent query) precludes a clear language semantics and thus, makes the implementation of the language and its usage much more difficult.
Novel and Intuitive View over (Reactive) Web Data XChange introduces a novel view over the Web data by stressing a clear separation betweenpersistent data (data of Web resources, such as XML or HTML documents) andvolatile data(event data communicated between XChange programs on the Web). Based on the differences between these kinds of data, the data metaphor is that ofwritten textvs. speech. XChange’s language design enforces this clear separation and entails new characteristics of event process- ing on the Web.
Language Design The design of the language XChange has received special attention throughout the whole development process; however, it is not that clear which kind of constructs should necessarily be included into a reactive language developed not only for a single kind of applications, but trying to cover different classes of applications. A tradeoff between the expressive power of the language and the ease of its usage has been looked for in designing XChange. On the other hand, the language XChange aims at acting as a ’referee’ language where the pattern-based approach has been investigated and used for specifying reactivity on the Web.
Event Queries with Double Purpose One of the essential traits of XChange event queries is that they have a double purpose: they are aimed forevent detectionandevent data extraction. Event queries in XChange not only detect atomic and composite events that have occurred on the Web and might require a reaction, they also extract pieces of information from incoming events by means ofvariables. The bindings for the variables occurring in event queries can be subsequently used for raising events or executing updates. Composite Event Queries Novel in XChange is its ability to detectcomposite eventson the Web, i.e. possibly time related combinations of events that have occurred at (same or different) XChange-aware Web sites. This is possible as XChange offerscomposite event queriesfor specifying interest in classes of events only if they are in particular temporal relationships.
Bounded Event Lifespan Events are not stored forever in memory, just as long as they are needed for answering the event queries registered at a Web site. The amount of time for which data on any received event is in memory – theevent lifespan– is bounded. This is aided by the fact that event queries areforward- looking(event queries do not query events received in the past). By design, the property of bounded event lifespan is enforced.
Declarative Semantics Declarative semantics are not only beneficial to avoid misinterpretations of lan- guage constructs by both users and implementors; they also provide a basis for formal proofs of language properties. However, the declarative semantics of other proposals for Web reactive languages is not pro- vided. A model theoretical semantics for XChange event query language has been defined as a ternary relation between an event query, an answer, and the stream of incoming events. The Web query language Xcerpt integrated into XChange provides a model theoretical semantics for the Web queries of reactive rules and for deductive rules. Moreover, this work on declarative semantics is used for the XChange update language, as the effect of an elementary update is the same as of a corresponding Xcerpt goal.
Use Cases Developing use cases for a language aims at introducing, removing, or modifying constructs of the language. It also reveals the strengths and limits of a language. The most substantial contribution of the use cases developed for the language XChange (some of them presented or touched on in this thesis, and some representing ongoing work) is that they bear evidence for the practicability of language constructs.
CHAPTER 7. CONCLUSION
7.2 Perspectives
The language XChange is an approach to reactivity on the Web; XChange has not saturated the research on reactivity on the Web, instead it aims at acting as a framework for further research work. Some of the perspectives for further work in XChange follow.
7.2.1 Transaction Management on the Web
The work on XChange has recognised the need for transactions (as combinations of possibly complex up- dates and events to be raised that are to be executed in an all-or-nothing manner) through developed appli- cation scenarios and the components a transaction on the Web might have (cf. Section 4.7). XChange pro- poses a syntax for (event-driven) transactions on the Web by specifying them as ’action part’ of XChange transaction rules (cf. Section 4.8.2). To some extent, the execution of actions in an all-or-nothing manner can be implemented by means of XChange reactive rules. However, as the discussion on transactions in Section 4.7.3 has shown, issues (such as the cascading triggering of local and remote actions inside a trans- action) need to be investigated and means need to be materialised fortransaction management on the Web. Database technology applied to Web data (such as XML or RDF) and the Web as environment can play an important role in realising this task. However, as Jennifer Widom already recognised “everything needs to scale to Web proportions (!).”1 Along this line, work on transactions in database management systems
such as [141, 66, 77] might prove very useful.
7.2.2 Generation of XChange Rules
The issue of generating XChange rules based on integrity constraints’ specifications is a promising per- spective for further work. The management of distributed projects is a good, concrete example where generating XChange reactive rules would be of real help. For example, the research project REWERSE (Reasoning on the Web with Rules and Semantics) has 27 participants each contributing to the project with its own members. At site http://rewerse.net information about the project, its participants, and its members can be found. Updating a member’s information results in updating multiple, distributed Web documents (e.g. home page data, member page data, working group involvement data). At moment this is done manually implying an amount of time and (surely) delays in gaining data accuracy. Thus, a kind of ’integrity-preserving rules’ need to be generated. This issue has been investigated in the context of active database systems, where different possibilities have been explored: (i) syntactic generation of event and condition parts, (ii) syntactic generation of event and condition parts, and declarative specification of action part, and (iii) syntactic generation of event and condition parts, and semantic generation of action part. A detailed discussion on these possibilities accompanied by examples and references can be found in [141], pages 264-270.
7.2.3 Efficiency Issues
This thesis has not considered optimising XChange event query evaluation and XChange update execution; a more efficient evaluation of Web queries is investigated at moment in the Xcerpt project. However, they leave room for research work aiming at a more efficient event query evaluation and update execution on the Web. One direction towards efficient event query evaluation is theclustering of XChange rules; the idea is to recognise event queries or parts of them that occur in more than one rule and to cluster rules into rule sets that can be associated with event classes. This method might be useful when the number of reactive rules is big (e.g. when implementing a large number of business rules by means of reactive rules). Clearly, a basis for a more efficient execution of updates on the Web would be provided by an update execution on secondary storage.
1Jennifer Widom, Data Management for XML, urlhttp://www-db.stanford.edu/ widom/xml-whitepaper.html