Archives

Anyone who has worked with more than one commercial rule engine knows that there are some significant performance differences between the various engines. In some cases the performance issues are so severe that you end up scratching your head, looking at the Gartner magic quadrant and trying to figure out how they put some of these turkeys where they did.

With Business Rules Engines we are, unfortunately, in a marketplace where information asymmetry and switching costs are the order of the day. Vendors don’t like to have their rule engines compared head-to-head and they use everything from custom rule description formats to alternate rule evaluation algorithms to rule repositories to legal restriction on making any performance measures public in order to make those comparisons difficult.

As a result, you see all sorts of claims from vendors about how nice their super secret algorithms perform. Peter Lin regularly takes on some of the more outrageous claims and, as best as he can, given the lack of information from the vendor, attempts to debunk them. His latest bit of skeptical wisdom, about the HyperRETE algorithm from EWA Systems, can be found here.

Ideally, we would have a standard rule description format, something like RuleML for example, and would use the rule engine as a standard execution environment with a standard set of API’s, etc. Vendors could differentiate their product offering by providing nice IDE and Rule Repository functionality or souping up their rule engine to provide better performance. Imagine Java IDE vendors clouding the issue by each shipping their own, non-standard JVM’s, tightly integrated with the IDE. If you want to run apps developed with their IDE, you need to use their engine and if you want to use their engine, you need to use their IDE.

In reality, Rule Engines should be a commodity by now. It’s just the lack of sophistication by IT managers that prevents them from evaluating BRE technology just like they would OS or database software.

So, what is a product manager to do? My advice is to evaluate as many rule engines as you can. If you need inferencing, i.e. the ability to chain together conclusions across a large fact base, make sure to evaluate RETE engines and make sure those engine are really really RETE. The best way to test the engines for performance and scalability is to build a prototype that replicates the rules and facts you are going to process. The academic benchmarks like Manners are all well and good, but if you are going to write lots of rules that involve 20 conditionals or the existential quantifier ("there are at least 3 instances of a bad credit reference"), you’re better off testing using that. If you’re expecting to chase a million customers through the rule engine every day, you want to know if you’ll need 4 or 400 CPU’s, so make sure to use enough representative data so you can accurately estimate performance.

If, instead, you swallow a vendors song and dance and fancy GUI interface, you deserve what you get. So, do your homework.

Share/Bookmark

Apparently we weren’t the only ones to notice Joel Spolsky’s rather empty observation on usability. John S. Rhodes over at WebWord also takes issue. He puts it very succinctly:

If a software product is meant for thousands of users, exactly who is expecting exactly what?

Indeed. I’d go a step further and say that what even one user expects from an application may change over time. For one, they may appreciate an application that provides training wheels early on and prefer one that lets them get down and dirty as they become experienced in the application’s domain.

Maybe it’s easy writing usable software if, like Joel, you stick to bug tracking software and the like. Come out into the real world and deal with non-technologists and you may get a rude reception.

Share/Bookmark

As far back as December of last year, Forbes was ringing the alarm bells about Ajax breaking the advertising business model:

While a popular approach to monetizing AJAX
applications is advertising, there is a problem: There are no "page
views." For example, suppose that on an AJAX Web page, you want to view
the body of a news article, so you click a news headline link. Rather
than refresh the entire page (a page view) as you would with a
traditional web page, the AJAX technology downloads just the body of
the news article and rearranges the Web page to present the article
content.

They go on to correctly point out that Ajax presents a potential boon to advertisers, with Ajax powered ads allowing them much greater control. I would add that it could give them a much greater ability to measure who is exposed to their ads and for how long.

"Adviews," i.e. the number of ads viewed (changing every X seconds) may become the new measure, rather than pageviews. Perhaps this will drive a change in site, getting them to make the page — rather than the site — more sticky, and getting rid of such annoying things as article splitting.

Share/Bookmark

I recently did a little unscientific comparison between the old Yahoo mail and the new Beta Ajax interface. The idea was to strap a non-caching proxy in front of the browser for a day each, clear the cache and see how they compared.

I fully expected to see the increase in requests and a decrease in request size that everyone talked about. I did see the former, but not much of the latter, as it turns out. The average request size was smaller for the Ajax version, but not that much smaller.

While this test wasn’t scientific — I just used my yahoo mail account as I usually do throughout the day — my educated guess is that the temptation to add lots of features to the new whiz-bang interface is the culprit.

Here, without further ado, are some of the facts and figures (count is number of requests. All others are in bytes):

Ajax Yahoo Mail

Old Yahoo Mail

What does this mean to you and your infrastructure requirements? Unless you exercise incredible discipline in pushing back on feature creep, you are likely to have Ajax apps that make more and bigger requests.

Remember when 1MB was more computer memory than anyone would ever need, or when car makers used the extra energy in those hybrid vehicles for greater fuel efficiency instead of more power of hybrid SUV’s?

Share/Bookmark

For those not wanting to hemorrhage the $10k plus for a development license of a BRE, there is a way of getting your feet wet with an open source rules engine: Drools

It is a real RETE (RETE OO, but who really cares?) implementation that you can use in your Java applications. There’s even a .NET version in BETA.

Rules can be written in several "dialects," such as straight Java

<rule name="Bootstrap 2">    <parameter identifier="f">      <class>Fibonacci</class>    </parameter>    <java:condition>f.getSequence() == 2</java:condition>    <java:condition>f.getValue() == -1</java:condition>    <java:consequence>      f.setValue( 1 );      System.err.println( f.getSequence() + " == " + f.getValue() );      drools.modifyObject( f );    </java:consequence></rule>

There are also dialects for Groovy, a java-like embedded scripting language, Python, etc. There is no "pseudo-natural language" dialect as yet, though this shouldn’t be all that hard. Really, most commercial BRE’s just rewrite method calls and expressions using a fairly primitive scheme, i.e. "IF truck.willFit(boxes)" translates to "IF the boxes will fit inside the truck." Of course the GUI IDE for this is a bit harder to write (though not impossible).

For me there’s still and open question on whether "pseudo-natural language" is really all that useful, but more on that in a subsequent post.

Note that Drools version 2.x does not support the universal or existential quantifiers of first order logic (see here for why this is important), but it is already useful for many different applications and performs pretty well in comparison to many commercial products. Support for full first order logic is planned for 3.x.
 

Share/Bookmark

Designer’s (of which I am one), are beginning to wrestle with the consequences of implementing Ajax, Flash and other rich interface technologies on the web. 
Among those consequences, is what to do with the "Back" button. It alone is responsible for almost 50% of web user clicks on today’s web.  However, it can lose its usefulness–In fact become somewhat of an obstacle– on sites powered by Ajax, Flash, and other Rich interface technologies. 
Mike Stenhouse of Content With Style believes that the back button is too important not to spend significant design and development time making certain it functions properly on Ajax web apps.  Without it…
The most fundamental online behaviour – click then back, is broken.
and sites become irritating at best, downright unusable at worst.  Ensuring that Ajax, as a web standard fails.  More here

Share/Bookmark

Part 1 of a multipart Echo2 tutorial series, entitled "Ajax with Echo2 and Eclipse" is now available from our web site. The related archive with the Echo2 distribution plus the EchopointNG library is available here.

I try to take to O’Reilly approache here, letting novices get their hands dirty by working on examples.

Stay tuned for part 2 real soon, where I show off a little bit of server push.

Share/Bookmark

These word processors are springing up like weeds. YAAWP (Yet Another Ajax Word Processor) is Zohowriter.  By only beef so far is that it has a few defects and doesn’t seem to behave quite like a desktop Word Processor. In particular, the text properties in the formatting bar don’t always change when selecting text in the document.

So, are all of these word processors actually useful, or is the word processor to Ajax applications what the chess program was to AI, aka "the drosophila of AI?"

Share/Bookmark

Many new network infrastructure management appliances are coming on the market, including several convergent devices which integrate many components together in one killer app(liance).

An example of this convergence is the new “F5 Big IP series” load balancing appliance that touts not only load balancing of server and application requests, but also firewall packet filtering and layer 7 application security, traditionally the domain of stand alone firewalls such as Checkpoint FW1.

While l see this convergence as a good thing for ease of management (one appliance to manage vs many) and lower rack space and power consumption, it comes at a much higher cost and misses some of the critical components the single focus applications/appliances provide. Either way it makes tech buying a more complex process trying to understand where each new device may fit in your organization.

When purchasing additional network functionality, in addition to standalone appliances tech buyers should evaluate convergent devices which may ultimately be a better fit for them. With the profusion of new appliances out there, understanding where the new offerings fit in your network requires a more knowledgeable and sophisticated buyer and VAR.

l will be writing an article soon discussing specific convergent devices, highlighting which offerings are suitable for which organizations.

Share/Bookmark