Chiba Integration

Overview

Chiba is an open-source XForms Server/Engine. Chiba uses XSLT to transform XForms markup to HTML for browsers without XForms support.

Recently we've been working on integrating the Smooks Servlet Filter into Chiba Web, replacing the current Chiba Web XSLT based UI Generation process with a Milyn Smooks Java based UI Generation process. This page documents the findings thus far.

main findings

Our initial findings indicate a dramatic improvement in performance over XSLT based transformations. On a Windows XP machine (1G Ram, 2GHz Pentium) the response-time benchmarkings were as follows (page - actions.xhtml from the Chiba Web distro).

Typical chiba response-times (using existing XSLT UI Generator):

• ~250 to 350ms

Typical chiba response times (using Smooks UI Generator):

• ~70 to 90ms

(Note, Chiba preprocessing without the UI Generation/Rendering step was benchmarked at ~50 to 70ms per request.)

So from these figures you can see that the overhead incurred using XSLT is quite significant when compared to Smooks based UI Generation (x10 to x15).

Note: These times are the times registered after Hotspot has warmed up the code i.e. 5/10 requests after startup.
Note: The transformations are not complete by any means. However, we're doing enough to give a good benchmarking figure. In fact, for the page against which the benchmarkings were taken (actions.xhtml from the Chiba Web distro), we're close to completing all of the transformations required for that page. This gives these benchmarking figures relevance.
Note: We recognise that it may be possible to make performance improvements to the Chiba XSLTs using techniques such as "indexing". How much would this improve performance? What effect would it have on the maintainability of the XSLTs?.

what was involved

1. Installed Chiba Web 2.0 in Jakarta Tomcat.
2. Disabled the Chiba XSLT UIGenerator.
3. Created and enabled a Chiba SmooksXML UIGenerator.
4. Integrated the SmooksServletFilter.
5. Developed a number of Smooks Java Content Delivery Units to perform transformations on Chiba preprocessed XForms content. Note we concentrated specifically on the actions.xhtml.

See the downloads section below for more details of how this integration is being done.

So what's the difference between the Smooks and XSLT approaches?

For this information, See the Smooks Comparisons page.

Downloads

1. chiba-web-viasmooks.war: Chiba Web with Smooks Servlet filter configured in place of the current XSLT UI Generator. Also includes the Timing ServletFilter to allow response-time benchmarking.
2. chiba-web-2.0.0rc1.war: Original Chiba Web distribution with the Timing ServletFilter configured to allow response-time benchmarking.

What to look at

The following image illustrates the locations of the resources relevant to the Smooks UI Generation process.

The main resources to look at are:

1. WEB-INF/smooks-cdr.lst,
2. WEB-INF/device-ident.xml and WEB-INF/device-profile.xml,
3. WEB-INF/cdr/xforms/html4.cdrl, and
4. The actual Smooks transformation in WEB-INF/classes.

The best place to start looking is the smooks-cdr.lst file. From here you can navigate to the other relevant files, including the transformations themselves.

For details on integrating the Smooks Servlet Filter into a Servlet container, see the SmooksServletFilter Javadocs.
For more information on other Smooks concepts, see the Smooks docs.

What is the Process of developing SmooksXML Transformations?

Once Smooks is configured into the Servlet container, the process of adding Smooks Transformations is typically as follows:

1. Write the Smooks Transformation: To do this, simply extend AbstractProcessingUnit. An example from the current work being done on Chiba would be the transformation for the xforms:input control. Start reading these transformations at the "visit" method.
2. Target the Smooks Transformation at the required markup element and browser/device combination: This is done by configuring the Transformation in a .cdrl file. As an example, see WEB-INF/cdr/xforms/html.cdrl.
3. Instruct Smooks to load the .cdrl file: This is done by configuring the smooks-cdr.lst file. As an example from the Chiba integration, see smooks-cdr.lst.

See SmooksXML for more information on developing Smooks Transformations.

Questions, Concerns & Comments

The following are some questions/concerns that have been raised about this approach to transforming content.

"Ok, java debugging capabilities are great but i'm still not sure if Smooks will give the flexibility for quick additions to the rendering. This capability is needed every day when working for customers."

First off, note that Smooks can be used to perform fragment based transformations using XSLT via the Smooks Templating Cartridge. However, this comparison is purely Java Vs XSLT.

"The no-compile-step" is probably one of the biggest arguments consistently made in favor of XSLT. We're hoping we can attract people to using Smooks based on the other advantages it can bring. From there (once people start using it), we think people will find that the modification turn around time with Smooks is not all that different from XSLT - a compile step (e.g. Ctrl-B in Eclipse) and an application redeploy in (e.g.) Tomcat Manager - all less than 10 seconds easily. Much of anything that is lost through the compile and redeploy steps should be retrievable through the other advantages brought by Smooks.

"How does Smooks deployed in a Servlet Container interact with existing jsp/xslt/servlet/struts etc applications? as a portlet perhaps?"

Because Smooks is not a templating solution, it typically doesn't get in the way of other frameworks - it's not responsible for "building the page". It's a ServletFilter, so as long as it sits in front of these other frameworks in the request chain, you're OK and it can do its job of manipulating the output for the requesting browser.

"What about XSL-FO?"

XSLT and XSL-FO are seperate processes anyway. So, you can use Smooks for FO generation in the same way as you'd use XSLT, and then use something like Apache FOP for the formatting. That said, this is not something we had in mind when creating Smooks.