A lot is known about matching. A lot of the work boils down to min cost network flows on a network with arcs with costs per unit flow and a maximum flow that is an integer. The problem, then, is integer linear programming but in this case the old linear programming simplex algorithm returns integer results for no extra effort. A nice modification is due to W. Cunningham, one of my profs, later Chair at Waterloo's Department of Combinatorics and Optimization.
What matching problem do you have in mind?
i'm working on a platform that helps hourly workers find jobs. today that matching is fairly straightforward, but it will get more complicated over time as we get develop better heuristics for matching candidates. it would be nice to be declarative about the matching rules and let the system figure out how to do the matching.
Sorry about that: I just couldn't see rules as an effective way to specify a problem or get a solution.
my very first consulting project (yes, i had absolutely no experience), around that time, was implementing blaze advisor (now owned by fico: http://www.fico.com/en/products/fico-blaze-advisor-decision-...) to migrate a mainframe-based automated life underwriting system to a j2ee client/server system.
performance was a major concern, so i read Forgy's 1982 paper about RETE (that i didn't quite understand frankly), but the key takeaway (for me at least) was that all the hard work happened during compilation so running performance shouldn't be an issue. from what i dimly remember, the algorithm iterates through the rules set building something akin to a decision tree until the tree reaches a stable state. if it never reaches stability, it will throw a compile error. once the tree is built, matching is very fast.
the holy grail was that "business analysts" (remember when that title was in vogue? =) could write the rules, saving you months of precious time and thousands of dollars by not paying programmers (it did not turn out that way of course).