[jboss-jira] [JBoss JIRA] (JBRULES-3585) Drools Planner should support JSR-331 too (for those that prefer math equations as constraints over object-orientated constraints)

[Geoffrey De Smet (JIRA)]

     [ https://issues.jboss.org/browse/JBRULES-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated JBRULES-3585:
--------------------------------------

    Description: 
JSR-331 is a constraint programming standardization effort and we could create a drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually wanting to use JSR 331.

Personally, I doubt many users would prefer math equations to write their constraints. Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner. Here's an example why I think that:

In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of it's depended services running in it's neighborhood
rule "serviceDependency"
    when
        $serviceDependency : MrServiceDependency($fromService : fromService, $toService : toService)
        $processAssignment : MrProcessAssignment(service == $fromService, $neighborhood : neighborhood)
        not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
    then
        // Constraint broken
end
{code}

In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
   for (MrProcessAssignment processAssignment : serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
       if (!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService()) {
           // Constraint broken
       }
   }
}
{code}

In JSR-331, which doesn't support Object-Orientation in it's constraints, this wouldn't look good.

  was:
JSR-331 is a constraint programming standardization effort and we could create a drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually wanting to use JSR 331.

Personally, I doubt many users would prefer math equations to write their constraints (vote on this issue to prove me wrong). Here's an example why:

In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of it's depended services running in it's neighborhood
rule "serviceDependency"
    when
        $serviceDependency : MrServiceDependency($fromService : fromService, $toService : toService)
        $processAssignment : MrProcessAssignment(service == $fromService, $neighborhood : neighborhood)
        not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
    then
        // Constraint broken
end
{code}

In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
   for (MrProcessAssignment processAssignment : serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
       if (!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService()) {
           // Constraint broken
       }
   }
}

In JSR-331, which doesn't support Object-Orientation in it's constraints, this wouldn't look good.


    
> Drools Planner should support JSR-331 too (for those that prefer math equations as constraints over object-orientated constraints)
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3585
>                 URL: https://issues.jboss.org/browse/JBRULES-3585
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Geoffrey De Smet
>            Priority: Minor
>
> JSR-331 is a constraint programming standardization effort and we could create a drools-planner-jsr331 to bridge that API.
> - Such a module shouldn't pose to many technical difficulties (it's basically translating the math equations in primitive based rules)
> - Such a module is a lot of effort none-the less. There need to be enough users actually wanting to use JSR 331.
> Personally, I doubt many users would prefer math equations to write their constraints. Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner. Here's an example why I think that:
> In Drools scoreDRL you say something like this:
> {code}
> // Dependency constraints: each process of a service must have at least one process of it's depended services running in it's neighborhood
> rule "serviceDependency"
>     when
>         $serviceDependency : MrServiceDependency($fromService : fromService, $toService : toService)
>         $processAssignment : MrProcessAssignment(service == $fromService, $neighborhood : neighborhood)
>         not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
>     then
>         // Constraint broken
> end
> {code}
> In a Java ScoreDirector, you say something like this:
> {code}
> // Dependency constraints: each process of a service must have at least one process of it's depended services running in it's neighborhood
> for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
>    for (MrProcessAssignment processAssignment : serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
>        if (!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService()) {
>            // Constraint broken
>        }
>    }
> }
> {code}
> In JSR-331, which doesn't support Object-Orientation in it's constraints, this wouldn't look good.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira