headers
Mark Proctor | 1 Nov 2010 07:24

Re: [rules-dev] exploring functional programming

Look at your responses i would say ignore the content of the examples, they are there just to illustrate the syntax not to show a valid use case or scenario. What I'm doing is looking to other languages to see what works there and try to bring them across, the CEP type uses cases rely a lot more on functional programming capabilities.

On 31/10/2010 13:01, Wolfgang Laun wrote:
Hello Mark,

I've been thinking about this, on and off, for 5 days now, and I still
fail to see the benefits. Perhaps there are more convincing use cases
than those in your original mail?

Notice that the "for" scope now contains two kinds of bindings: one that
is strictly local to for(...) (bi below) and another one that must be exported
such as the binding $s in

  for( bi : BasketItem( customer == $c ); $s = sum( $bi.price); )
We can certainly make it:
$s : sum(....)

My thinking is we still need to create a sytnax to assign the results of the expression when it returns a collection, instead of iterating it. For this I was thinking of introducting:
$var = someexpr;

We can't do the following as there isn't enough of a differentiator in the syntax between normal patterns.
$var : someexpr;

But we can do = for assignment of expr, but keep : for bindings of a functional result. Just seeing how different things look.

This will be confusing.


I fail to see the usefulness of filter() in

   for( $b2 : BasketItem( customer == $c ); filter( $b2, $b2.price > 100) )
filter is just a function, like min, max and average, it's not special. Functional programming has a number of higher order functions, filter, map and fold. There is nothing extra to support that, so it's just added for completeness to show we could/can do it.

where one can better (and perhaps even more efficiently) write

   for( $b2 : BasketItem( customer == $c, price > 100) )
The filter function was just an example for completeness, it could have been any function name.

I don't understand what this construct should achieve:

    $r = $bi | map( $, $.price * 2) | filter( $, $.price < 100);
I wouldn't take the example as "best practice"or actually meaningful I was just trying to illustrate the syntax.

Given that $bi iterates over BasketItem objects, the first map would create
a numeric value by doubling $bi.price, so I suppose the next pipeline transmits
numbers so that filtering applies to - what? java.lang.Number? Then it can't be
$.price;
The contents is automatically passed into the function. The first argument is what the higher order "map" function would store, the second one is the modifier. Typically "map" is single argument map( * 2 ), but I can't see how that would work for our syntax, especially when passing objects instead of values.

it could be $.floatValue or similar. But again: the entire selection
could be written as a constraint of the BaskerItem pattern. Creating a
collection just for determining a count isn't straightforward.

The idea of accumulate is to produce a scalar result from processing a
collection of facts.
It would indeed be useful to extend this so that a result
tuple can be constructed. But this could be achieved by a complex
accumulate function that returns an object with multiple fields;
in fact, min/max/count/avg/sum can be wrapped into a single function
"stats" returning an object of class "Statistics" with appropriate fields.
Any filtering on the result can be written as a constraint on that
temporary fact pattern of type Statistics, e.g.:

Statistics( $min: min, $max: max )
  from accumulate( $bi: BasketItem( $p: price ) stats( $p ) )
that's something that can be achieved now, but requires plumbing from the end user. Multiple functions support would avoid that and is what people from other products would expect. The last part of the acc provides the propagation constraint, it's sugar to avoid verbosity.

All that remains is the syntactic sugar that's provided by
   x in [0..4]
   y in [0..4]
   $c : Cell( row == y, col == x );
as a on-the-fly pattern for selecting other patterns. Again, this could be
written more concisely as
Don't take the example as "best practice". It's showing that 'in', which is the same as 'from', can look more compact and is what people from a more functional world would expect.

i'm thinking of allowing 'from' and 'in' to be used interchangable. Where 'from' would be used with "from entry-point" where as 'in' for iterationg the results of an expression.

 CEP cases can also need specific ordering, the example below could find the cells in any order.
  $c : Cell( row >= 0 && <= 4, col >= 0 && <= 4 )
and a (minor) extension such as a set expression might simplify this:
  $c : Cell( row in [0..4], col in [0,1,2,3,4] )

Regards
Wolfgang

On 26 October 2010 01:36, Mark Proctor <mproctor <at> codehaus.org> wrote:
We are thinking of moving "accumulate" to a simple "for" keyword. We
might allow 'in' and 'from' to be used interchangably and allow ';' semi
colons to separate the sections. I'm also wondering ho we could allow
function pipelines for the function part of the element. We also need
type inference and "default" return values.

So here are some code snippets to show what I'm thinking, as
improvements over what we do with accumulate now.

// Simple 'or' very simlar to accumulate before. ; for section
separating. With a new boolean section at the end to decide whether to
propagate or not. Will probably use '=' for function assignments.
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $s = sum( $bi.price);
        $s > 100 )

// Multiple functions are ofcourse allowed
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $mn =min( $bi.price),
        $mx = max( $bi.price); )

// As are multiple patterns, and as before patterns can come 'from' an
expression and with type inference we can get some nice compact text:
for ( x in [0..4]
      y in [0..4]
      $c : Cell( row == y, col == x );
      $avg = avg( $cell.value );
      $avg > 100 )

The above is possible now with the following:
Integer( this > 100) from
    accumulate( x : Integer() from [0, 1, 2, 3, 4]
                y : Integer() from [0, 1, 2, 3, 4],
                $c : Cell( row == y, col == x ),
                avg( $c.value) )

I think the proposed additions reall help with declarative readability.

The normal chaining of elements is supported:
$c : Customer()
for( $b1 : BasketItem() in
          for( $b2 : BasketItem( customer == $c );
                 filter( $b2, $b2.price > 100); );
        $a = avg( $b1.price ); )

'for' will have a default return type for each bound function. In this
case it returns a single value $a, if there are multiple bound results
an array/map must be used for access.

I also think we should allow pipelineing of functions, much as you would
do in a normal functional programming, possibly using haskell like
"stream fusion" capable functions.

// '$' refers to the magic contents of the function which is "piped" in.
So $bi is piped to map, $ refers to each value evaluated in the
function, with type inference. 'map' results are piped to 'filter'. The
final results are assigned to $r.
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $r = $bi | map( $, $.price * 2) |
                       filter( $, $.price < 100);
        $r.size > 100 )

More ideas welcome :) But I think this opens up some very interesting
areas for DRL, with something that will hopefully feel more natural for
developers.

Mark

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 1 comment |
headers
Wolfgang Laun | 1 Nov 2010 09:21
Picon

Re: [rules-dev] exploring functional programming

Well, meaningful examples sure would help :)

(1) On binding: Did I understand this correctly:
A legacy binding denoted by <var> ':' is restricted to the scope of 'for'.
The assignment <var> '=' creates a binding that can be used locally but is exported (for use in other CEs or on the RHS).

But note that a legacy form binding may not be usable until the end of the "for", only until the first contracting transformation (see function F below).


(2) On functions: Examples appear to illustrate (at least) 2 kinds of functions:
T : Coll<X> -> Coll<X>, a mapping of a collection of type X to the same domain
F : Coll<X> -> Y, a folding of a collection of type X into a single instance of type Y (which could be = X)
Possibly you are also thinking of simple functions that map between single instances:
g : X -> Y

The tricky part here is the transformation type T (such as map()). How will this work in the case
  map( $, $.price*2)
You can't change the objects in the domain collection. So, how will the result be built? Will X have to implement Cloneable? What if the field (here: price) does not have a setter? map applies a function to a list of the function's domain values, which is very well for *values*, but we're living in an object-based environment. [Other transformations such as reverse() or tail() do not imply changes on the components.]

Another example, using a Collection<String> as input; the mapping should produce the uppercased strings, concatenated:
   for( String( length > 10 ); map( $, $.toUpperCase() ); $c: concatenate( $ ) ) # not sure about the last '$'
But what if I want to implement a transformation such as "every 'x_y' to 'xY'"? How would I specify this function so that map can call it? Java currently does not have functions as objects (and I think the terrible proposal for closures has been shunted into a very dead end track). Or would I have to implement each non-trivial map-type function anew, from scratch? Then map isn't a higher-order function at all!

Finally, permit me to say: If every currently implemented feature were well documented, both in manuals and javadoc, and readily usable, downloaded distributions without broken links (e.g. in javadoc) and missing libraries, and if there were no serious open JIRAs - then, and only then, I'd say that this is worth the time and the effort. I do beg your pardon if you think this is coarse or boorish, but these are my sentiments, and they had to come out, sooner or later.

Cheers
Wolfgang





On 1 November 2010 07:24, Mark Proctor <mproctor <at> codehaus.org> wrote:
Look at your responses i would say ignore the content of the examples, they are there just to illustrate the syntax not to show a valid use case or scenario. What I'm doing is looking to other languages to see what works there and try to bring them across, the CEP type uses cases rely a lot more on functional programming capabilities.


On 31/10/2010 13:01, Wolfgang Laun wrote:
Hello Mark,

I've been thinking about this, on and off, for 5 days now, and I still
fail to see the benefits. Perhaps there are more convincing use cases
than those in your original mail?

Notice that the "for" scope now contains two kinds of bindings: one that
is strictly local to for(...) (bi below) and another one that must be exported
such as the binding $s in

  for( bi : BasketItem( customer == $c ); $s = sum( $bi.price); )
We can certainly make it:
$s : sum(....)

My thinking is we still need to create a sytnax to assign the results of the expression when it returns a collection, instead of iterating it. For this I was thinking of introducting:
$var = someexpr;

We can't do the following as there isn't enough of a differentiator in the syntax between normal patterns.
$var : someexpr;

But we can do = for assignment of expr, but keep : for bindings of a functional result. Just seeing how different things look.


This will be confusing.


I fail to see the usefulness of filter() in

   for( $b2 : BasketItem( customer == $c ); filter( $b2, $b2.price > 100) )
filter is just a function, like min, max and average, it's not special. Functional programming has a number of higher order functions, filter, map and fold. There is nothing extra to support that, so it's just added for completeness to show we could/can do it.


where one can better (and perhaps even more efficiently) write

   for( $b2 : BasketItem( customer == $c, price > 100) )
The filter function was just an example for completeness, it could have been any function name.


I don't understand what this construct should achieve:

    $r = $bi | map( $, $.price * 2) | filter( $, $.price < 100);
I wouldn't take the example as "best practice"or actually meaningful I was just trying to illustrate the syntax.

Given that $bi iterates over BasketItem objects, the first map would create
a numeric value by doubling $bi.price, so I suppose the next pipeline transmits
numbers so that filtering applies to - what? java.lang.Number? Then it can't be
$.price;
The contents is automatically passed into the function. The first argument is what the higher order "map" function would store, the second one is the modifier. Typically "map" is single argument map( * 2 ), but I can't see how that would work for our syntax, especially when passing objects instead of values.


it could be $.floatValue or similar. But again: the entire selection
could be written as a constraint of the BaskerItem pattern. Creating a
collection just for determining a count isn't straightforward.

The idea of accumulate is to produce a scalar result from processing a
collection of facts.
It would indeed be useful to extend this so that a result
tuple can be constructed. But this could be achieved by a complex
accumulate function that returns an object with multiple fields;
in fact, min/max/count/avg/sum can be wrapped into a single function
"stats" returning an object of class "Statistics" with appropriate fields.
Any filtering on the result can be written as a constraint on that
temporary fact pattern of type Statistics, e.g.:

Statistics( $min: min, $max: max )
  from accumulate( $bi: BasketItem( $p: price ) stats( $p ) )
that's something that can be achieved now, but requires plumbing from the end user. Multiple functions support would avoid that and is what people from other products would expect. The last part of the acc provides the propagation constraint, it's sugar to avoid verbosity.


All that remains is the syntactic sugar that's provided by
   x in [0..4]
   y in [0..4]
   $c : Cell( row == y, col == x );
as a on-the-fly pattern for selecting other patterns. Again, this could be
written more concisely as
Don't take the example as "best practice". It's showing that 'in', which is the same as 'from', can look more compact and is what people from a more functional world would expect.

i'm thinking of allowing 'from' and 'in' to be used interchangable. Where 'from' would be used with "from entry-point" where as 'in' for iterationg the results of an expression.

 CEP cases can also need specific ordering, the example below could find the cells in any order.

  $c : Cell( row >= 0 && <= 4, col >= 0 && <= 4 )
and a (minor) extension such as a set expression might simplify this:
  $c : Cell( row in [0..4], col in [0,1,2,3,4] )

Regards
Wolfgang

On 26 October 2010 01:36, Mark Proctor <mproctor <at> codehaus.org> wrote:
We are thinking of moving "accumulate" to a simple "for" keyword. We
might allow 'in' and 'from' to be used interchangably and allow ';' semi
colons to separate the sections. I'm also wondering ho we could allow
function pipelines for the function part of the element. We also need
type inference and "default" return values.

So here are some code snippets to show what I'm thinking, as
improvements over what we do with accumulate now.

// Simple 'or' very simlar to accumulate before. ; for section
separating. With a new boolean section at the end to decide whether to
propagate or not. Will probably use '=' for function assignments.
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $s = sum( $bi.price);
        $s > 100 )

// Multiple functions are ofcourse allowed
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $mn =min( $bi.price),
        $mx = max( $bi.price); )

// As are multiple patterns, and as before patterns can come 'from' an
expression and with type inference we can get some nice compact text:
for ( x in [0..4]
      y in [0..4]
      $c : Cell( row == y, col == x );
      $avg = avg( $cell.value );
      $avg > 100 )

The above is possible now with the following:
Integer( this > 100) from
    accumulate( x : Integer() from [0, 1, 2, 3, 4]
                y : Integer() from [0, 1, 2, 3, 4],
                $c : Cell( row == y, col == x ),
                avg( $c.value) )

I think the proposed additions reall help with declarative readability.

The normal chaining of elements is supported:
$c : Customer()
for( $b1 : BasketItem() in
          for( $b2 : BasketItem( customer == $c );
                 filter( $b2, $b2.price > 100); );
        $a = avg( $b1.price ); )

'for' will have a default return type for each bound function. In this
case it returns a single value $a, if there are multiple bound results
an array/map must be used for access.

I also think we should allow pipelineing of functions, much as you would
do in a normal functional programming, possibly using haskell like
"stream fusion" capable functions.

// '$' refers to the magic contents of the function which is "piped" in.
So $bi is piped to map, $ refers to each value evaluated in the
function, with type inference. 'map' results are piped to 'filter'. The
final results are assigned to $r.
$c : Customer()
for( $bi : BasketItem( customer == $c );
        $r = $bi | map( $, $.price * 2) |
                       filter( $, $.price < 100);
        $r.size > 100 )

More ideas welcome :) But I think this opens up some very interesting
areas for DRL, with something that will hopefully feel more natural for
developers.

Mark

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 0 comments |
headers
Christine Karman | 1 Nov 2010 10:15
Picon
Favicon

Re: [rules-dev] backward chaining

On 10/29/2010 04:32 PM, Mark Proctor wrote:
> We have a prototype of BC that works, but won't be ready until Q1 next 
> year.
Is that in the svn? Is it a separate project in svn, or is it part of 
the trunk?

dagdag
Christine
> Mark
>> dagdag
>> Christine
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

--

-- 
dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 4 comments |
headers
Wolfgang Laun | 1 Nov 2010 10:39
Picon

Re: [rules-dev] backward chaining

Mostly out of curiosity:
I have implemented a few things using full-blown backward chaining and
I know that these things could have been implemented just as well using
forward chaining. Therefore: Why does your project "need" bw chaining?
Of course, if you have a good algorithm based on that, it may be easier
to stay with it.
-W

On 1 November 2010 10:15, Christine Karman <mylists <at> christine.nl> wrote:
On 10/29/2010 04:32 PM, Mark Proctor wrote:
> We have a prototype of BC that works, but won't be ready until Q1 next
> year.
Is that in the svn? Is it a separate project in svn, or is it part of
the trunk?

dagdag
Christine
> Mark
>> dagdag
>> Christine
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>


--
dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 3 comments |
headers
Christine Karman | 1 Nov 2010 11:44
Picon
Favicon

Re: [rules-dev] backward chaining

On 11/01/2010 10:39 AM, Wolfgang Laun wrote:
Mostly out of curiosity:
I have implemented a few things using full-blown backward chaining and
I know that these things could have been implemented just as well using
forward chaining. Therefore: Why does your project "need" bw chaining?

A forward chaining engine finds all premisses and then draws all conclusions it can make, recursively. A backward chaining engine finds all goals, then tries to satisfy them using available facts. If no facts remain and no goal has been satisfied, the system should ask a user. A forward chaining engine would never find unsatisfied goals, so it would never try to acquire additional information, unless you specifically program it to do so. Basically, by doing that you build in a backward chaining component.

I have built quite a few expert systems that used both backward chaining and forward chaining. Either one wouldn't have done the job.

dagdag
Christine

Of course, if you have a good algorithm based on that, it may be easier
to stay with it.
-W

On 1 November 2010 10:15, Christine Karman <mylists <at> christine.nl> wrote:
On 10/29/2010 04:32 PM, Mark Proctor wrote:
> We have a prototype of BC that works, but won't be ready until Q1 next
> year.
Is that in the svn? Is it a separate project in svn, or is it part of
the trunk?

dagdag
Christine
> Mark
>> dagdag
>> Christine
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>


--
dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev


-- dagdag is just a two-character rotation of byebye. 
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 2 comments |
headers
Wolfgang Laun | 1 Nov 2010 12:17
Picon

Re: [rules-dev] backward chaining

On 1 November 2010 11:44, Christine Karman <mylists <at> christine.nl> wrote:

On 11/01/2010 10:39 AM, Wolfgang Laun wrote:
Mostly out of curiosity:
I have implemented a few things using full-blown backward chaining and
I know that these things could have been implemented just as well using
forward chaining. Therefore: Why does your project "need" bw chaining?

A forward chaining engine finds all premisses and then draws all conclusions it can make, recursively. A backward chaining engine finds all goals, then tries to satisfy them using available facts. If no facts remain and no goal has been satisfied, the system should ask a user. A forward chaining engine would never find unsatisfied goals, so it would never try to acquire additional information, unless you specifically program it to do so. Basically, by doing that you build in a backward chaining component.

I have built quite a few expert systems that used both backward chaining and forward chaining. Either one wouldn't have done the job.


Indeed, requesting additional facts makes all the difference.
Thank you!
Wolfgang
 
dagdag
Christine


Of course, if you have a good algorithm based on that, it may be easier
to stay with it.
-W

On 1 November 2010 10:15, Christine Karman <mylists <at> christine.nl> wrote:
On 10/29/2010 04:32 PM, Mark Proctor wrote:
> We have a prototype of BC that works, but won't be ready until Q1 next
> year.
Is that in the svn? Is it a separate project in svn, or is it part of
the trunk?

dagdag
Christine
> Mark
>> dagdag
>> Christine
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>


--
dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev


-- dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 1 comment |
headers
Christine Karman | 1 Nov 2010 13:46
Picon
Favicon

Re: [rules-dev] backward chaining

On 11/01/2010 12:17 PM, Wolfgang Laun wrote:

Indeed, requesting additional facts makes all the difference.

:-)
Most expert systems I've built in the past, when building expert systems was "en vogue", we built systems that would engage in a dialogue with the user, using expert knowledge (heuristic knowledge) that we put in. The tools proved too limited though: the commercial expert system shells didn't provide the flexibility, and the systems we built from scratch (in C) turned out to be too expensive. That's why I'm happy with Drools, it provides flexibility, extensibility while it's easy to use.

dagdag
Christine

Thank you!
Wolfgang
 
dagdag
Christine


Of course, if you have a good algorithm based on that, it may be easier
to stay with it.
-W

On 1 November 2010 10:15, Christine Karman <mylists <at> christine.nl> wrote:
On 10/29/2010 04:32 PM, Mark Proctor wrote:
> We have a prototype of BC that works, but won't be ready until Q1 next
> year.
Is that in the svn? Is it a separate project in svn, or is it part of
the trunk?

dagdag
Christine
> Mark
>> dagdag
>> Christine
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>


--
dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev


-- dagdag is just a two-character rotation of byebye.

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev


-- dagdag is just a two-character rotation of byebye. 
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 0 comments |
headers
tizo | 1 Nov 2010 16:31
Picon

[rules-dev] Drools Flow in EJBs

On Wed, Oct 27, 2010 at 5:21 PM, tizo <tizone <at> gmail.com> wrote:
Hi there,

I have seen in chapter 6 of the documentation, that Drools Flow can be configured to use JPA and transactions to persist the running states. However, I am in a EJB where I obtain entity managers with a <at> PersistenceContext annotation, and the transactions are managed by the container, whereas in the example an EntityManagerFactory and a TransactionManager are used.

Could I configure Flow in a direct way to be used by my EJB?

Thanks very much,

tizo


Ok, looking at the code, I guess that Drools flow is not ready to work with standards EJBs. The reasons are the following:

 * The JPA annotations are not standard JPA annotations, but hibernate ones. For example "CollectionOfElements" in ProcessInstanceInfo class.
 * Transactions are managed by Drools, as opposed to some EJBs where transactions are managed by the container.

As for that, I will probably modify the codes, so Flow could be used in our EJBs. I would like to know if someone could guide me on what should I modify.

I will post the modifications in case they are of interest to someone.

Thanks very much,

tizo


_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 4 comments |
headers
Mark Proctor | 1 Nov 2010 19:21

Re: [rules-dev] Drools Flow in EJBs

On 01/11/2010 15:31, tizo wrote:
On Wed, Oct 27, 2010 at 5:21 PM, tizo <tizone <at> gmail.com> wrote:
Hi there,

I have seen in chapter 6 of the documentation, that Drools Flow can be configured to use JPA and transactions to persist the running states. However, I am in a EJB where I obtain entity managers with a <at> PersistenceContext annotation, and the transactions are managed by the container, whereas in the example an EntityManagerFactory and a TransactionManager are used.

Could I configure Flow in a direct way to be used by my EJB?

Thanks very much,

tizo


Ok, looking at the code, I guess that Drools flow is not ready to work with standards EJBs. The reasons are the following:

 * The JPA annotations are not standard JPA annotations, but hibernate ones. For example "CollectionOfElements" in ProcessInstanceInfo class.
That was the one element we couldn't find a replacement for in JPA1, JPA2 fixes this, but we haven't updated to JPA2 yet. I don't believe we use any other hibernate specific annotations.
 * Transactions are managed by Drools, as opposed to some EJBs where transactions are managed by the container.
You can use both JTA transactions and local entity transactions. So transactions can be drools maintained or container/external maintained.

As for that, I will probably modify the codes, so Flow could be used in our EJBs. I would like to know if someone could guide me on what should I modify.

I will post the modifications in case they are of interest to someone.

Thanks very much,

tizo


_______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev 

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 3 comments |
headers
tizo | 1 Nov 2010 20:05
Picon

Re: [rules-dev] Drools Flow in EJBs



On Mon, Nov 1, 2010 at 4:21 PM, Mark Proctor <mproctor <at> codehaus.org> wrote:
On 01/11/2010 15:31, tizo wrote:
On Wed, Oct 27, 2010 at 5:21 PM, tizo <tizone <at> gmail.com> wrote:
Hi there,

I have seen in chapter 6 of the documentation, that Drools Flow can be configured to use JPA and transactions to persist the running states. However, I am in a EJB where I obtain entity managers with a <at> PersistenceContext annotation, and the transactions are managed by the container, whereas in the example an EntityManagerFactory and a TransactionManager are used.

Could I configure Flow in a direct way to be used by my EJB?

Thanks very much,

tizo


Ok, looking at the code, I guess that Drools flow is not ready to work with standards EJBs. The reasons are the following:

 * The JPA annotations are not standard JPA annotations, but hibernate ones. For example "CollectionOfElements" in ProcessInstanceInfo class.
That was the one element we couldn't find a replacement for in JPA1, JPA2 fixes this, but we haven't updated to JPA2 yet. I don't believe we use any other hibernate specific annotations.

 * Transactions are managed by Drools, as opposed to some EJBs where transactions are managed by the container.
You can use both JTA transactions and local entity transactions. So transactions can be drools maintained or container/external maintained.

As for that, I will probably modify the codes, so Flow could be used in our EJBs. I would like to know if someone could guide me on what should I modify.

I will post the modifications in case they are of interest to someone.

Thanks very much,

tizo

Mark,

Thanks for your response. Could you tell me how can I use Drools with my container managed transactions, or where can I read how to do that?. I think that the example given in the documentation (Drools Flow, 6.1.4 - Transactions) does not apply to this case, and I can't figure out how to do it.

Thanks again,

tizo


_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Permalink | Reply | 2 comments |

Gmane