There is an interesting relationship between the RETE algoritnm and an emerging field called Join Calculus. The RETE algorithm has always suffered from a sense of being ad-hoc, it works therefore it is, without any real explanation for why it works so well in so many situations. Join Calculus may be able to provide a more general grounding for building rule engines than RETE, or at least give RETE a stonger theoretical foundation.

An extended quote from Efficient Compilation of Guarded Join-Patterns via Parallel Implementation of Constraint Handling Rules by Edmund S. L. Lam and Martin Sulzmann at the School of Computing, National University of Singapore ( slightly reformatted but otherwise exact ). Note that CHR stands for Constraint Handling Rules.

Apart from CHR, there are other candidates (constraint logic programming languages, rule bases systems, databases) which are possibly applicable as solutions to the problem of efficient guarded join-pattern compilation.

For instance, the Rete algorithm [?] used by many production rule systems is an efficient approach for computing multi-object pattern matchings by incrementally building matches from partial matches. However, such incremental matching algorithms are not entirely suitable in the context of join-patterns due to a fundamental problem: Such approaches incrementally and exhaustively accumulates partial matchings to build complete matchings.

In join-patterns messages are consumed (deleted) immediately when they match with a join-pattern, making all matchings involve these deleted constraints obselete and hence constituting wasted computations. Solutions from the database context (in building joins between tables) also suffers from the same redundancy. The CHR refined operational semantics [3] on the other hand defines a goal directed execution strategy for processing multi-set constraint pattern matching only by demand, since most of the CHR rule rewritings involve deleting matched constraints. This makes CHR multi-set constraint matching algorithms highly appropriate for triggering guarded join-patterns.

I'm not sure I understand the implications of this ( in fact, I'm pretty sure that I don't ), but it seems to be offering a more efficient and general analytic framework for building rule engines. It might also be a more powerful construct for integrating rule engines with the Pi-calculus employed in workflow engines than current pattern-matching algorthms.