It wasn't easy. But now it is. Tohu!
Tohu is ...
• Designed to support question and answer style interactions where the set of questions are dynamic and potentially dependent on the answers received
• Initially targeted at interactive web applications, however technology independent and could be used in B2B scenarios, mobile devices, etc
• An embeddable component that complements and works within existing UI frameworks such as Seam/JSF/Spring MVC
Tohu closes the development and maintenance loop for rule based web applications, by automatically generating user interfaces directly from rule sets.
Tohu has been applied in the insurance, financial, education, medical, and government sectors. It has also been used by students for research projects.
Origin of the name
Tohu is a Maori word meaning to guide, advise, or instruct.
There are 3 core components:
- Questionnaire rule support. This is a set of Java based classes that enable specific Questionnaire rules to be created and used in a rule based application.
- Rule Execution Server (a.k.a Drools Camel Server). While this is actually a separate project, it is listed here as it is a fundamental part of the solution. The execution server provides a service interface into the Rule Engine (output is XML or JSON - currently only XML is supported in Tohu).
Users of Tohu can leverage standard Drools capabilities (including Guvnor/BRMS).
Why is this needed?
Consider the scenario where customers use a web application to apply for a Loyalty Card scheme, requiring the conditional gathering of different personal details from a user. If the business wants to gather an additional piece of information as part of the process of refining the rules used to determine the applicants suitability then we would usually need to have a standard web development effort lasting at least several weeks. However, if the user interface for the new data can be automatically generated from the rules, then we are now talking days to get it through the required testing phases and into production. Now that's business agility.
Another scenario may be that you want to put up a relatively simple 3 page questionnaire with conditional content where the details are simply put into a PDF and mailed to the HR manager. In this case why not write the rules to capture the data and conditional logic, and have Tohu generate the User Interface for you.
Now we are starting to talk about IT enabling true business agility.
What is the real difference we are aiming for?
There is a large difference between making and testing code changes as compared to data changes. With a well tested generic library it is no longer the case that we are testing the library every time we are making a change. Instead, we are only needing to test the rule changes. This effectively transforms the process from one of managing a coding effort to one of managing data changes, which dramatically reduces IT dependancies and puts control much more in the hands of the Business Owners.
That being said, it is not a panacea for all IT ills! We are applying the 80/20 rule and keeping the focus tight and simple. Other approaches will be more appropriate in certain circumstances (Drools may still be applicable even if Tohu is not). It also does not do all that an application would be expected to do (hence the focus on making this "embeddable" within a wider application context). Any attempt to tackle the last 20% would likely lead to another bloated all-encompassing UI framework, and that is NOT what Tohu is trying to be!
For further documentation, see the Wiki at http://www.jboss.org/community/wiki/Tohu
If you find a bug or have an idea for improvement, please raise it in Jira: https://issues.jboss.org/browse/TOHU
Also if you're using Tohu then it would benefit others if you're able to contribute back to the project either code enhancements or by improving the documentation on the Wiki e.g the FAQ page: https://community.jboss.org/wiki/Tohu-FAQ