@Formula migration is much simpler than LotusScript. You can have a library of Java functions that reproduce the Domino @functions using native Java. The problem, more generally speaking, is not the language translation, but rather the Domino object model (the LotusScript API and certain @functions such as @DbColumn, @DbLookup, @DbName, etc.) that does not exist in the J2EE world. Outside of Domino, there is only one third-party framework that offers a port of the Domino "Note" concept by using XML instead of the proprietary "Note" format in Domino, and reproduces the NSF store, Domino object model and @functions in native Java.
It is important to understand porting the document-centric database/document/view paradigm to relational is a difficult exercise. Absent of a third-party framework, you would need to manually construct the relational data model and tables, corresponding to each form, and then write SQL Queries in lieu of views and SQL Select, Insert, Update, Delete using JDBC in your JSP forms. The problem with this method is that Notes documents not only contain data, but also metadata such as creation date, modification date, readers, authors, $REF (for response documents), workflow control fields, etc. This metadata would require special handling in the target relational data model, which can be more or less tedious depending on how much of this metadata should carry over in the target J2EE application.
The J2EE community has recognized the need for a document management API standard and there is a proposed specification of an API (JSR 170) to satisfy this need in the future. Unfortunately, this JSR is still a couple of years away, and it's not specifically meant to provide an alternative to the Domino object model. Nevertheless, it's a promising first step from the JCP towards document-centric development in J2EE.
Do you have comments on this Ask the Expert question and response? Let us know.
This was first published in August 2004