Rule Driven User Interfaces
I happened to stumble across this post while going thru my unread items in Google Reader the other day. It basically describes the strategy we've used at work doing a re-write of a sales tool for insurance.
It's a pretty powerful way of doing it but we've also stumbled upon several rather complex issues in handling the nitty-gritty details of using a Rule Engine together with JSP/Servlets and Apache Struts. It's quite easy to get a simplistic solution up and running but if you want to fit it into an existing architecture or framework you've got some work to do.
Unfortunately, I can't go into detail about it here but I hope to spend some time on the subject in an open source setting and provide some examples and running code because it is definitely worth doing if you can get it right.
Labels:
Rule Engine
4 kommentarer:
those techniques are actually fairly old. As far back as the mid 90's people were doing that with thick clients using ART and Mindbox products. In the case of mindbox, they employ case base reasoning with rule engines, so it can be quite powerful.
The limitations I've seen with using JSP/Servlets with rule engines is really about managing a pool of rule engines. Depending on the type of load the application has to support, one can use 1 request per engine, or do it in an async way. In async approach, the rule engine is shared and the tricky part is where to store the state. Do you store the http session in the rule engine? If you do, how do you expire the session and make sure it propogates a retract in the rule engine. If you use the rule engine in a stateless manner, how do you make sure requests are processed in a timely manner.
Another approach is to write the rules in a declarative manner and compile the rules to java code. this gives you the benefit of lower overhead with the benefits of a central rule repository and rule governance. Just some random thoughts.
We never tried using several rule engines so we didn't have that particular problem, but as you've already guessed most of them are related to handling state together with an HTTP Session.
We had some additional restrictions as well. Nordea have an existing framework/architecture for J2EE applications that forced us to make some compromises. It made it more difficult in some ways but allowed us to re-use test environments, deployment frameworks, existing application servers etc. I'd say that it's in those areas the most challenging problems show up.
Even though Rule Engines aren't exactly new, I've found surprisingly few developers and architects that feel comfortable enough to use them. I really can't say why it is so. I'm guessing it's a "branding" problem since most developers seem willing to try and use (and stick up for), for example, Hibernate even though it bit them hard in the first project they tried it.
Hi Peter,
It has been quite some time since we participated in a conversation.
Now, I would say that what you describes one possible way for approaching this problem. I have another take on this problem.
Maintaining state with a rule engine is tricky and should not really be attempted as typically rule engine calls, I believe are Stateless.
Using a Rule Engine for controlling Page flow, I am not sure is really the intent with RDUI's.
RDUI's provide a lot of value a Q&A kind of a scenario where previous answers determine the next set of questions. And the questions that the UI ask of the user generally define the screens.
I would even go one step further and say that, depending on the content, the UI could even be dynamically generated
there's lots of example. Say for example I have a complex questionnaire for tech support. The users starts answering the questions. based on the answer, the UI determines which questions should appear next.
another example might be loan application where the user may be asked to provide more or less data based on the type of loan and the applicant's responses.
I think both examples broadly fit into the idea of page flow. Depending on the situation, one may want to use a rule engine in a stateful manner. In these two cases, it's probably safer not to. If on the other hand, the questionnaire has 500 questions and complex flows, it might make sense to use the rule engine in a stateful manner.
managing rule engine state can be tricky. Users need to understand when to use it and make good judgements. that's one area the industry has done a poor job.
Skicka en kommentar