This chapter summarizes the process of designing NAS applications and offers guidelines for effective design.
Identifying Application Requirements
Assembling the Development Team
Designing the User Interface
Guidelines for Effective Development
security
high number of end users (high concurrency)
high performance and scalability
specific features: account transfers, account reporting, online trades, special offers to qualified customers
different types of end users; for example, individuals, corporations, or internal users (bank employees)
internal reporting
The Architect
Team Roles for the Presentation Layer
Team Roles for the Business Logic Layer
Team Roles for the Data and Legacy Access Layer
Java servlet developers
JSP developers
HTML designers
graphic artists
client-side JavaScript developers
Ensure that HTML appears properly across different browser clients.
Ensure that HTML loads efficiently across slow modem connections.
Improve the appearance of pages initially designed by JSP developers.
Session bean developers
Entity bean developers
CORBA applications
mainframe systems
third-party security systems
What is the page flow?
What commands and buttons are available on each page?
Will the pages use frames or not?
Are there any corporate standards that determine headers and footers, logos, menu bars, or banner ads?
At what point is login required?
Are there any international issues? For example, are the icons or cartoon images meaningful to all users? Does translation pose a formatting problem?
Are the commonly used features easy to find?
Easing Development
Maintaining or Reusing Code
Improving Performance
Planning for Scalability
Design the UI first; this assumes you know something about the datasources that the application must access.
Use servlets for presentation logic; user JSPs for presentation layout.
Develop servlets and JSPs that can conditionally generate different pages.
Choose base classes, helper classes, and helper methods in a way that encourages code reusability.
Use relative paths and URLs, so that links remain valid if you move the code tree later.
Minimize the Java in your JSPs; instead, put Java in servlets and helper classes. JSP designers can revise JSPs without being Java experts.
Use property files or global classes to store hardcoded strings such as the names of datasources, tables, columns, JNDI objects, or other application properties.
Use session beans, rather than servlets and JSPs, to store business rules that are domain-specific or likely to change often, such as input validation.
Use entity beans for persistent objects; using entity beans allows management of multiple beans per user.
For maximum flexibility, use Java interfaces rather than Java classes.
Use extensions to access legacy data.
In most cases, deploy servlets and JSPs to NAS rather than to the Netscape Enterprise Server (NES) web server. NAS is best if an application is highly transactional, requires failover support to preserve session data, or accesses legacy data. NES is useful if an application is mostly stateless, read-only, and non-transactional.
Use entity beans and stateless session beans; design for colocation to avoid costly remote procedure calls.
When an application is deployed, ensure that the necessary EJBs and JSPs are replicated and available to load into the same process as the calling servlet.
When returning multiple rows of information, use JDBC RowSet objects when possible.
When committing complex data to a database, use efficient database features, such as JDBC batch updates or direct SQL operations.
Follow general programming guidelines for improving performance of Java applications.
Store scalar or serializable information in HttpSession objects that are configured to be distributed.
Avoid using global variables.
Design the application as if it will run in a multi-machine environment (also called a "server farm").