You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Dan Haywood (JIRA)" <ji...@apache.org> on 2016/05/17 19:33:12 UTC

[jira] [Updated] (ISIS-1360) Declarative Invariants

     [ https://issues.apache.org/jira/browse/ISIS-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Haywood updated ISIS-1360:
------------------------------
    Fix Version/s: 2.0.0
      Description: 
I think that one aspect of the amplification concept Apache ISIS provides might be to allow some degree of declarative business rules / invariants. There is an interesting open source project (1) that allows a Java application to define declarative business rules / invariant you might want to fork.
 
The difference between some other business rules engines (say RETE compliant) is that most business rules engines focus on conditional business rules or decision business rules only, and work outside the application scope, as an external API returning results that you must incorporate into your code with even more code. This one´s focus (ABL) is transactional business rules, which work through the persistence manager (Hibernate´s JPA in this case), so you don´t need to call any rules to be triggered, rules are automatically triggered when you persist data. Thus, it lets you use the previous values before saving and after saving to trigger rules (update inventory with new value of received quantity - old value of received quantity + old value of inventory).
 
In summary, it provides:
•        Declarative rules, like: 
o   InvoiceItem.amount = InvoiceItem.quantity * InvoiceItem.unitPrice * (1 + VAT / 100)
o   Invoice.amount = sum(InvoiceItem.amount) if InvoiceItem.status != “deleted”
o   account balance = sum(invoice.amount) if status = “due
•        Automatic sequencing of the rules. This is really great, because instead of sequenced lines of code, you create independent rules, which you can maintain and change completely separate from all other rules. You can even have a rules manager and document each rule.
•        Automatic execution of the rules every time you do an insert, update or delete to any of those entity objects. Any change executes the rules properly. If a new rule implies altering the sequence of the execution of rules, this happens automatically and seamlessly. 
•        Extensibility (create your own rules). Create a new weightedAverage () rule. 
•        Documentation. You can document your rules, associate rules to topic or groups, like use cases where they come from.
 
 
(1)    http://www.automatedbusinesslogic.com/


  was:
I think that one aspect of the amplification concept Apache ISIS provides might be to allow some degree of declarative business rules / invariants. There is an interesting open source project (1) that allows a Java application to define declarative business rules / invariant you might want to fork.
 
The difference between some other business rules engines (say RETE compliant) is that most business rules engines focus on conditional business rules or decision business rules only, and work outside the application scope, as an external API returning results that you must incorporate into your code with even more code. This one´s focus (ABL) is transactional business rules, which work through the persistence manager (Hybernate´s JPA in this case), so you don´t need to call any rules to be triggered, rules are automatically triggered when you persist data. Thus, it lets you use the previous values before saving and after saving to trigger rules (update inventory with new value of received quantity - old value of received quantity + old value of inventory).
 
In summary, it provides:
•        Declarative rules, like: 
o   InvoiceItem.amount = InvoiceItem.quantity * InvoiceItem.unitPrice * (1 + VAT / 100)
o   Invoice.amount = sum(InvoiceItem.amount) if InvoiceItem.status != “deleted”
o   account balance = sum(invoice.amount) if status = “due
•        Automatic sequencing of the rules. This is really great, because instead of sequenced lines of code, you create independent rules, which you can maintain and change completely separate from all other rules. You can even have a rules manager and document each rule.
•        Automatic execution of the rules every time you do an insert, update or delete to any of those entity objects. Any change executes the rules properly. If a new rule implies altering the sequence of the execution of rules, this happens automatically and seamlessly. 
•        Extensibility (create your own rules). Create a new weightedAverage () rule. 
•        Documentation. You can document your rules, associate rules to topic or groups, like use cases where they come from.
 
 
(1)    http://www.automatedbusinesslogic.com/



This probably needs to be spiked to figure out in more detail how it would work.  Possibly it could be implemented as a subscriber that can apply the declarative rules, based on when one of the inputs change.

Worry that we might be trying to reinvent Excel here, though.

> Declarative Invariants
> ----------------------
>
>                 Key: ISIS-1360
>                 URL: https://issues.apache.org/jira/browse/ISIS-1360
>             Project: Isis
>          Issue Type: Bug
>          Components: Core, Core: Objectstore: JDO
>    Affects Versions: 1.12.0
>            Reporter: Cesar Lugo
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> I think that one aspect of the amplification concept Apache ISIS provides might be to allow some degree of declarative business rules / invariants. There is an interesting open source project (1) that allows a Java application to define declarative business rules / invariant you might want to fork.
>  
> The difference between some other business rules engines (say RETE compliant) is that most business rules engines focus on conditional business rules or decision business rules only, and work outside the application scope, as an external API returning results that you must incorporate into your code with even more code. This one´s focus (ABL) is transactional business rules, which work through the persistence manager (Hibernate´s JPA in this case), so you don´t need to call any rules to be triggered, rules are automatically triggered when you persist data. Thus, it lets you use the previous values before saving and after saving to trigger rules (update inventory with new value of received quantity - old value of received quantity + old value of inventory).
>  
> In summary, it provides:
> •        Declarative rules, like: 
> o   InvoiceItem.amount = InvoiceItem.quantity * InvoiceItem.unitPrice * (1 + VAT / 100)
> o   Invoice.amount = sum(InvoiceItem.amount) if InvoiceItem.status != “deleted”
> o   account balance = sum(invoice.amount) if status = “due
> •        Automatic sequencing of the rules. This is really great, because instead of sequenced lines of code, you create independent rules, which you can maintain and change completely separate from all other rules. You can even have a rules manager and document each rule.
> •        Automatic execution of the rules every time you do an insert, update or delete to any of those entity objects. Any change executes the rules properly. If a new rule implies altering the sequence of the execution of rules, this happens automatically and seamlessly. 
> •        Extensibility (create your own rules). Create a new weightedAverage () rule. 
> •        Documentation. You can document your rules, associate rules to topic or groups, like use cases where they come from.
>  
>  
> (1)    http://www.automatedbusinesslogic.com/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)