First of all, thank you very much for the support and prompt detailed answers. Our industry-class and enterprise-scale application (finance) is successfully running in production (SunOneServer/JATO 1.2).
JATO performs extremely well (even combined with our original very fat object framework encompassing session management, workflow processing, business rules engine, etc., etc.). Moreover, there is no performance degradation for large number of concurrent users. Extremely large and over-loaded with business logic pages (JATO's very thin JSP is over 150K!, e.g.) just fly and it is hundred percent dynamically multilingual (parallel content!).
A couple of notes regarding to the discussion JATO vs. Struts or vice versa, since another application of the company uses Struts framework and we could compare.
1. If application should be migrated from ND to J2EE (probably it is a closed stage in the industry) it must be JATO (iMT tool does its job very well).
2. If the application should be written from the scratch the demarcation line is the size and complexity of the project. For any enterprise size and complex application it has to be JATO as well. Formalized model and event driven architecture allows easily implement/include/add the best design patterns throughout the application. Elimination of thread safe programming for developers leads both to rapid bug-less development and good performance under load (much better to refer to the originators' articles). From my personal point of view, JATO has modern, very balanced and extensible architecture and it is just nice to work with it.
3. For small/medium size application it could be either one or another. It really depends on different factors (further company goals, staff skills, staff education time, etc., etc.).
Now why I am using JATO abbreviation, not S1AF. There is still no official announcement from Sun with regards to the S1AF code access (please correct me if I am wrong). Conversion of the JATO 1.2 based project to S1AF is not easy if the project integrated with non-Sun IDE (in our case, we have JBuilder). Thus, it is could be a critical to get this answer. Personally, I prefer to stay with JATO 1.2 (even without interoperability with the code generator GUI) having the access/control to the framework rather than to use reliable GUI as a black box.
Please do not consider this as a criticism. I just don't know details, it is totally out of my responsibilities, and I would like to be wrong with my assumption. Nevertheless, from my point of view, closing of the access to the source code could probably hurt S1AF's market expansion. Struts source code is open (and will be open) by default and this is the today's mainstream. JATO is very good and matured, but not easy beast and one of the most efficient way to learn it is to read the code. I definitely know, that people choosing the MVC framework in the industry has been already taking this factor into account. It doesn't mean, of course, that the GUI tool itself should be free.
Let me be more precise with some historical excurse. NetDynamics policy was to close the access to the source code and use it as a black box (with a very good set of documentation). It was a common practice in pre-J2EE time, but took a lot of extra hours to get the result sometimes. Who knows where the NetDynamics would be if they had chosen opposite approach.
Finally, thank you very much again for such a good product. Every single word in the white paper is true. If I have any choice for my further projects, I will stick with this state-of-the-art MVC implementation (JATO or S1AF) again.
Vladimir Ivanov, Senior Java Architect, Ph. D. in Applied Mathematics