"The tedious text list manipulation through scripting necessary to simulate hierarchical data structures (e.g., dynamic tables) in Domino is an idiosyncracy of the flat data format of a Notes document, which simply doesn't exist in a hierarchical XML document," he told me. "The conversion process gives you the opportunity, not only to migrate the data, but to normalize it as well. You can't build an accounting system in Domino, but you can in FlowBuilder."

This claim to convert the data store from NSF (Notes Storage Facility) to XML/RDBMS does not mean that we can transform our NSF dross into J2EE gold with a single push-button. Migrating away from the NSF data store means no more dual Notes/Web client development (or support), as only a browser can access a J2EE server. Any features specific to the Notes client UI, such as LotusScript form events, will be obsolete. On the other hand, FlowBuilder 3.0 also offers new features that the Domino architecture lacks, so any application will require analysis before a conversion. But merely moving data out of Domino onto another application framework isn't what sets FlowBuilder 3.0 apart from a crowd of Web-application server competitors. What is equally appealing as its migration capabilities is the preservation of Domino's Rapid RAD environment.

Domino developers have been hesitant to jump into J2EE, in general, and WebSphere, in particular, because of the additional layers of complexity. A Domino database is a single file that contains the user-interface, all application logic, and a flexible data-store. The J2EE model calls for a model-view-controller construction that separates the data, its presentation, and the controller translating interactions with the view into actions to be performed by the model (a readable introduction to J2EE can be found at http://www-106.ibm.com/developerworks/java/library/j-roadmap1).

J2EE makes sense for large-scale application development (e.g., eBay), but may be excessively elaborate for many corporate applications. Flowbuilder 3.0 bridges this divide with its facility to migrate the architecture and maintain the Domino developer's RAD orientation.

FlowBuilder architecture
To start with FlowBuilder 3.0 is to understand its architecture, as shown in Figure A: a combination of two servlets, the FlowBuilder server and the XSP server, that integrate with a Web application server, an LDAP (Lightweight Directory Access Protocol) directory and an RDBMS. The term "XSP" is how Trilog describes the process of transforming the XML into server pages, and has nothing in common with the XSP associated with the Apache Cocoon project.

FIGURE A

Here you can see the basic FlowBuilder 3.0 components. Click picture for a larger image.

The first servlet, the FlowBuilder 3.0 server, delivers six properties, most of them centered on its workflow capabilities:

1. A BizDAP (Business Directory Access Protocol) service used for workflow applications in accessing LDAP (or a Domino directory) and defining relationships that are more complex than mere authentication.
2. A process service for workflow;
3. A log service for checking workflow statistics;
4. A delegation service for workflow role definitions;
5. A router service for processing the workflow routing; and
6. A task manager service for calling JavaScript or Java routines.