Monday, December 17, 2007

Drools Javapolis BOF on our Business Logic Platform

I did a Drools BOF at Javapolis, where I presented what I believe is the future :) our vision on a unified and integrated business logic platform. You won't go to separate proprietary vendors for rules, processes and cep - each with their own runtime, api and server side management/deployment; your business logic is too important to be tied into closed source proprietary frameworks. We will provide the end users with a single platform with fully integrated rules, processes and cep with a single runtime, api and server side management/deployment. I have made available the slides from the presentation here, which are at a technical level, and you'll see this delivered in phases of 2008.


  1. Just a random comment. The since/until syntax feels a bit awkward to me. Why not use "while" keyword instead of since/util?

    From a concept perspective for the logging example. The system should write logs while the user session is active. It makes it simpler to validate and is more concise.

    another comment about time window. Although StreamSql uses time.window I think it is ambiguous. It is better to be precise. the CEP blog and Event process thinking both make great points about the ambiguity and problem of interpreting "time.window". If the time is absolutely, or relative, the language should make that clear. If I want the top 5 matches within a given time window, it should be clear. I don't believe time.window is sufficient to express the user's intent clearly.

    the more I think about StreamSql from a language design perspective, the more I think it is poorly thoughtout. Rather than tackle temporal logic with precise semantics, they've hacked on time.window without really thinking it through. I don't know the right solution, but StreamSql's approach feels wrong for a long term solution.

    my bias 2 bits from designing DSL over the years.

  2. Hmm... I think the "while" statement is well overloaded now. Since basic in the 70's I think most people (even non programmers **) think it means iterations/looping, which I think is not the intent here.

    ** from a study of one non programmer (the wife).

  3. You're right "while" is overloaded in programming terms. I was thinking from an english language perspective. Business users typically don't have the baggage that programmers have.

    From a consistency perspective, have 2 keys words since/until leaves it wide open for all sorts of inconsistency. The patterns in "since" must be consistent with "until".

    From a DSL perspective, "while" is a description of the state and shouldn't involving any looping. It's a very hard choice to make. On one hand, we have years of programming baggage and on the opposite side, it's hard to find a keyword that fits as nicely.

    The same argument can be made about NOT pattern. I'm inclined to say "while" is the best candidate even if there's baggage behind the word.

    A potential option is "forstate", similar to "forall". though forall likewise is a bit overloaded. Someone new to rules might think forall in rule languages is the same as java's forall loop.

  4. Peter,

    'Since' and 'Until' have formal semantics defined in US Modal Logic (see Kripke semantics). What we are implementing is consistent with that modal logic.

    Please note that:

    1. 'since' and 'until' accept any CE, the same way that "exists" or "not". They don't need to work on a single pattern or even be symmetrical to each other.

    2. Once 'since' CE is matched, the time window becomes active and continues active even if the 'since' CE becomes "false" (i.e., stops matching). The window only closes when the 'until' pattern is matched. This is again, consistent with US Modal Logic. This is different from the behavior you was suggesting for the "while" CE.

    Having said that, the syntax per se, may still change until the final release, but we do want to use 'since' and 'until' as the keywords because it is a known CE for those using temporal reasoning.

    my 2c.

  5. Interesting. That's the reason I feel it's dangerous and too complicated. I have a hard enough time explaining NOT, Exists and Forall to developers. Trying to explain since/until makes it that much harder.

    I'm sure there people who want that kind of functionality, but I'm guessing it's a very advanced feature. The question I ask myself is this.

    Do most people think that way?

    Mentally keeping track of since/until with dozens of even hundreds of rules is going to create a huge learning curve for the user.

    I suppose the user could keep the rule count low (less than 2 dozen), but from first hand experience, users do things without taking time to understand the theory behind it. Of the dozen rule developers I interviewed this last year that claimed to have 3-5 years of blaze or jrules experience. Only 1 or 2 understood how to use NOT and Exists correctly.

    Even fewer understood rule theory, so asking the developer to understand more formal logic is asking a lot. Of course, deciding which features to implement based purely on lowest common denominator (ie regular developer) isn't a good idea.

    I think it's admirable drools tackling modal temporal logic. ART, CLIPS, JESS, Blaze and most other engines do not tackle it. I'm no expert on modal logic, but the literature out there is dense. One could spend 30 years studying temporal modal logic and figuring out how to use it correctly.

    Going with a symmetric approach may cover 98% of the cases, without adding a huge learning curve for the user. Just some food for thought.

  6. Was thinking that 'while' might make a good keyword, but not as an alternative to since and until. We can have a window that is open while a pattern is true - definitely some uses for that. So room for both I think.

  7. I agree they are different. One is symmetric and the other non-symmetric. Asymmetric is much more powerful than symmetric. There are things symmetric isn't going to cover. If the rule editor provides deep analysis, it could be user friendly. From my limited understanding, proving and analyzing the asymmetric case is rather hard for the general case. Honestly, I don't think I could keep track of more than 2-3 dozen rules with since/until.

    one potential approach to make since/until easier to use is to generate a state chart of all the since/until rules. If a since condition has the potential of always being true, the editor can highlight it with a different color. Ultimately, the user has to be an expert to use it correctly.

  8. some more random thoughts about generating a state chart for since/until rules. all of it may be garbage, but I thought it might inspire or lead to better ideas.

    Take a webapp for example. The simplest case is figuring out if the user is logged in. Drawing a state chart is rather simple, since the user is either authenticated or not.

    A more complex case might be an online application with dozens of steps. Now the state chart is more complicated and might cyclic.

    How can make it easier? One approach is to start from a state chart and generate the rules. Writing the rules in some language and generating a state chart for validation is probably going to be much harder. By starting with state chart, the user views it from a higher level abstraction.

    When I worked at verizon online, we had to integrate with several third party vendors. One of the biggest challenges was mapping our transaction states to the other vendors. In many cases, we had extra states and the partners had extra states. To resolve that, we had to figure out if those extra states matter to us and whether our system should be indempotent for those states.

    From a finite state machine perspective, since/until rules should take these factors into account. Whether that is easy to do is uncharted territory. Last year I worked on a general purpose algorithm for translating acyclic graphs like business process into rules. For the simple case it was trivial.

    In a way, a business process graph is like a state chart. the main difference I see is that a state chart tends to be cyclic, whereas bpm graphs "generally" aren't. Actually that statement isn't true for the general case. For service oriented transaction, it might be true. The more I think about this problem, the more complex it becomes.

  9. Dear Mark,

    Thanks again for your tasty BOF at Javapolis07, it was a pleasure meeting you.

    As you suggested me to post it, here is the feature request we talked about:

    Our company often has to code time spans across working hours for ticketing systems (issue tracking/service calls) in accordance with ever-changing SLA (service level agreements). Those times calculi are PAINFUL in an imperative language.

    Therefore I wish I could have a modification of the 'duration' principle that would allow the coding of such rules:

    a customer ticket is opened for more than two hours during working_hours_2008
    and state is urgent
    send a reminder to the support team and the team leader
    a customer ticket is opened for more than four hours during working_hours_2008
    and state is urgent
    and no action taken
    escalate ticket

    This might require:
    * A scheduling mechanism such as quartz (sort of java combination of 'at' and 'cron' Unix commands with extension capabilities) to trigger the second assertion of the LHS at a specific time.
    * New syntax tokens: during, "for"
    * New nonterminal symbols after these tokens (composite date and time classes)

    I have since then had a talk with Stephen Colebourne at Javapolis; he is the responsible of the JSR 310 Date and Time API (

    I have proposed him to extend the scope of the JSR to accept composites of DatesWithoutTime and TimeIntervals objects to enable the retrieval of a OffsetDateTime by calculating the span of a Duration trough a CompositeDateAndTimeInterval.

    An example is much more clear:
    CompositeTimeInterval working_hours = EnhancedTimeInterval(Mon tru fri 8:00 to 20:00)
    TimeInterval lunchbreak = 12:00 to 12:45
    CompositeDateWithoutTime belgiumBankHolidays2008 = 1 Jan 2008, 23 Mar 2008, 24 Mar 2008, 1 May 2008, 11 May 2008, 12 May 2008, 21 Jul 2008, 15 Aug 2008, 1 Nov 2008, 11 Nov 2008, 25 Dec 2008
    CompositeDateWithoutTime specialOpeningDays = Sun 20 Feb (launch of our new super awaited product), Sun 21 Dec (shopping day before Xmas)
    CompositeTimeInterval working_hours_2008 = new CompositeTimeInterval()

    This composite is to be used after the 'during' token. The duration would require its own syntax token (the word 'for' is already overused in programming languages, it could lead to confusion)

    These composites would have to be defined somewhere at sometime for the BRE to access them. Could they be directly defined in rule packages? Or accessed as

    Thus, in order:
    * assert LHS's CEs
    * calculate the time span of the duration across the 'agenda' (also a confusing keyword, would it be good English to call it schedule?)
    * set an event in the future for the matched object
    * when it’s event time: callback the object LHS assertion
    * and if still true, execute RHS

    I would be very happy to contribute to the implementation of this feature, please let me know if you (and your team) are interested in such a feature.

    Looking forward to hearing from you,

    Stanislas Herman Rusinsky.