Well, after the beating that everyone's taken - just a word of experience regarding BRE's and Linux on z. Note, these are my observations and opinions in a general sense, and should not necessarily be construed as the "rule". Obviously some of these statements can be debated endlessly, but I want to be general in the sense of a bell curve general.
I've seen BRE's now running on several platforms, and with a fair variety of success - but there's several keys to success that can make or break an implementation. First, the BRE itself can be coded such that it is efficient and uses the platform to its benefit - we've seen and had some in CICS and IMS for some time, and they're very efficient. However, a BRE ported to a different environment than it was written on can be an issue - particular in terms of High Level Language and the associated factors there. In essence, 1) you lose efficiency for every language level you go up (assembler to C++ to Java, for example). 2) If the BRE is written "well", it should run "well" anywhere - but if it's written under the guise that it only needs to run on a dedicated server, then CPU and memory can be said to not "matter", and it could run very poorly indeed in a shared environment. 3) If the BRE takes advantage of a particular hardware infrastructure (say, CPU affinity for L2 Cache context switching protection) then it may run much worse in an environment like System z where L2 Cache is shared on ALL processors. 4) A BRE is also a "language" of sorts, and therefore another level of programming - poorly written rules can cause all kinds of trouble - just like poorly written code. 5) You (almost) always pay in performance when you look for ease in programming/maintenance. 6) BRE's are tunable - make sure you are well versed in the performance aspects of all elements of the BRE from Linux through the Application Server to the Database and the BRE itself. All that said, my experience has been that BRE's with complex or large rulesets, as a general rule, run with very high CPU requirements, and may perform quite poorly on System z if taken by themselves. Of course, as a shared workload, and if SLA's are lenient, this could be OK. I've seen BRE's on other platforms run equally horrible, and the costs escalate as more and more hardware is thrown at the problem. (Again, was the ruleset optimized? Was the BRE right for the platform? How can you find out? I can't answer these questions.) My gut impression, for now, is that BRE's run well in a horizontally scalable architecture like grid, rather than a vertical one. Now we can scale well horizontally in System z, and there could always be something in the future that can mitigate the BRE performance issues on any platform. In my mind nothing beats a well built, well programmed application FIRST, and the right software for the right purpose. All statements above are my own, and in no way should be taken as those of my employer, just my experience. Regards, Paul Giordano Technical Sales Specialist - Linux on System z e-business Solutions Technical Sales, Americas (312) 529-1347 (630) 207-9435 (cell) email: [EMAIL PROTECTED] Linux on 390 Port <[email protected]> wrote on 07/03/2007 04:10:23 PM: > BRE : Business Rules Engine > > It's what the software sales people are now selling to big shops. > > http://en.wikipedia.org/wiki/Business_rules_engine > > > Anton Britz > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
