I've recently had an opportunity to give Corticon a test run. Corticon consists of desktop rule studio and a server component that runs the rules. The server component can be embedded inside a Java application, or run as a standalone server. The studio is used to create a vocabulary and the rule sets.
The approach Corticon uses is quite novel in comparison to the other rule engine vendors. They don't use the Rete Algorithm, instead they rely on compile time rule linking. This means that the rules are deployed to the server compiled, and the rule firing order is already calculated. The concept is undoubtedly more palatable to some organizations that find traditional rule engines a little unyielding.
The other novel idea is that the rules are compiled against a vocabulary (an ontology, if you will) rather than an object model. This means that you can submit dynamic datasets to the rule engine rather than relying on strict structures as is the case with Jboss Rules. It also seems that Corticon has licensed the Oracle XML SDK, which allows them to query the database, retrieve the result in XML, pipe it to the rule engine, and produce a result, all without any custom code. The actual rule writing and vocabulary management occurs in the desktop rule studio. The studio gives a user a decision tree type of interface but with some enhancements. The rule writing is done in a 4th generation language, meaning that the rule author uses the vocabulary, boolean algebra, truth tables, discrete math type of programming, "table driven algorithm programming". It's quite nifty but comes off a little limiting to a hard core developer.
And now for the negative:
In order to extend the language, you need to write java code, and then add it to the classpath of the desktop rule studio. This means that if you distributed the desktop rule studio to your business analyst, now you have to redistribute your jar file. You will need to redistribute a new jar file every time you extend the library with a new function. This is almost impossible to do in large organizations with dumb terminals, software packaging, etc...
The actual desktop rule studio is cluncky and is missing some basic keyboard shortcuts, like the "delete" key. There is also no security of any type. The rule author is able to change the vocabulary and any rules. The actual 4gl language at times seems more confusing than it's 3GL counterpart.
For the developer, Corticon is a disaster. The API library consists of a handful of classes. One to create a server, and run the rules. Another to deploy the rules to the server, and yet another to do some admin RMI calls to the desktop rule studio. Mind you, RMI calls for an enterprise level application is a little laughable. The functionality of the RMI calls are also a little silly. You can start the studio, shut it down, and open a vocabulary. In comparison, ILOG has an immense API library. I would wager that you can pretty much control any aspect of ILOG. And of course, JBoss Rules is open source, which makes them quite friendly to developers.
And yet more negativity:
There is no way to control the rule firings. There is also no way to disable certain rules from firing, or manage the rules in a central location. The mere fact that the rules are compiled in the desktop rule studio by the rule author and written as a file in binary format makes any form of enterprise rule management a joke. A nice web 2.0 gui for rule management like with Drools or ILog would also be nice. Why is it that I need a desktop app to manage my rules?
In summary, I think Corticon is quite a nifty concept, but is not a mature enterprise framework. It maybe useful in some limited fashion as glue logic, but it doesn't belong as an enterprise class rule engine. At least, not yet.
An addendum: Tibco iProcess has licensed the Corticon Rule engine for it's decision server. This does not change my opinion of Corticon, but reduces my opinion of Tibco. As a side topic, I think Tibco Business Work is an impressive tool, but the entire iProcess stack is quite bad and convoluted. I think Tibco just wanted to put something out quickly, so, they pieced together some varying half finished technologies.
Subscribe to:
Post Comments (Atom)
4 comments:
You might not be aware of it, but those techniques are over a decade old. It's commonly known as "static analysis" or "pre-computed rules". In fact, there's dozens of papers that go into the approach. Anyone with a good understanding of rule engines, expert systems and pattern matching is familiar with those techniques. Contrary to what Corticon claims, they didn't invent the approach. Instead, they "re-invented" it instead of looking at prior research.
According to Corticon, they call their approach "design time inference". Which is a fancy word for "we try to make rule authoring easier." Statically compiled decision trees have their place, but it's not as flexible or robust as a mature expert system approach like CLIPS, JESS, and JRules.
Also, we have TIBCO's own rule engine (TIBCO BusinessEvents), which can be used in lieu of iProcess Decisions. More usually it is used to drive BPM / iProcess though, as its an event-driven rule engine. And yes, it separates technical and business user interfaces clearly.
Cheers
Greetings:
Corticon calls what they do DETI, Design Time Inferencing. The math that they claim to be part of the optimization process is doubtful since they don't show you what they do. ("Pay no attention to the man behind the curtain." - Wizard of Oz) That being said, what they do is basically static and, to my way of thinking, not a flexible as a true rulebased system.
On the other hand, you must consider that ILOG, FICO, and others now have sequential rules that are nothing more than what Corticon is doing. Even the "Decision Tables" by FICO, ILOG and Drools are extremely similar to Corticon in that each row is a rule that is static as well.
Visual Rules and VisiRules are code generators, Visual Rules from a spreadsheet and VisiRules from a model driven process. They, too, are static processes.
All of that being said, why be critical of a company who is doing the same thing to the rulebase industry as the others except they don't have the fall-back position of a real inference engine should they need it? They (ILOG, FICO et al) gave their "stamp of approval" to the bastardization of the rulebase industry when they started down the Decision Table, Decision Tree, Compiled Sequential route a long time ago. Now that somebody is giving them the "come-uppance" that they deserve, the begin to whine like a mule. It makes you want to gag at the gall and hypocrisy of it the "Big Four" vendors.
SDG
jco
(Google went brain-dead and would not recognize my ID/Passwd so I just left it and went back to my Google blog. Stupid Computers!!)
Hello, I'm Dr. Mark Allen, the CEO and Co-founder of Corticon. I felt obliged to comment on this post and provide some clarifications. First, I really appreciate the feedback, even the negatives. We try hard to deliver products that meet the needs of the market, and know that we can't always please everyone.
I want to start by acknowledging our core design principle: simplicity is complexity resolved. We work hard to hide complexity in order to empower mere mortals to do awesome things. Without a doubt, this is a loss for hardcore developers who like to get their hands dirty in code.
That said, it is crucial to point out that Corticon BRMS has great flexibility and robustness, and has been proven across hundreds of customers to handle the most sophisticated decisioning problems, including traditional inferencing problems. We respectfully challenge anyone to define rule-based problems that Corticon BRMS cannot handle.
In fact, there are some significant advantages to our unique engine algorithm (called DeTI). First, the execution logic is much easier to understand (contrary to some comments, we both describe the theoretical design of DeTI and generate execution flows for specific rule sets). Second, DeTI has proven to perform much better than Rete with large working memories (a known problem with Rete). This is very significant for some of the problems that our customers address. (Of note, the first version of Corticon used the Ilog JRules engine. We built our own engine after struggling through performance problems in our early customers.)
Some other clarifications worth noting:
- Corticon has developed an object-relational technology that enables a direct connection between the rule engine session and an RDBMS, where queries are auto-generated from the business rules (called Corticon Enterprise Data Connector). This is not licensed from Oracle, nor does it translate through an XML layer. Our customers have found this to deliver about twice the performance of application-driven data connectivity.
- Corticon provides a separate rule repository product to centralize rule management, control rule asset lifecycles via workflows, and apply security and access control (called Corticon Collaborator, which may not have been evaluated).
- The newest release (v5) provides a massively broader set of APIs allowing all capabilities of rule modeling and execution to be governed through programming (we call this API set Corticon Foundation, also likely not evaluated).
- There are numerous ways to control rule firing and to disable individual rules and rule sets. We are happy to show anyone interested how this is done.
Hopefully this helps to clarify some of the statements. Best regards,
Mark
Post a Comment