Chapter 1   Designing iAS Applications


This chapter summarizes the process of designing iAS applications and offers guidelines for effective design.

Designing applications for iAS involves four main steps, described in the following sections:

• Identifying Application Requirements

• Assembling the Development Team

• Designing the User Interface

• Following Guidelines for Effective Development

Identifying Application Requirements

---

In any development cycle, the first step—and arguably the most important step—is to gather the requirements of the application. This step may take weeks or months, and it involves your product management or product marketing team.

As a brief example, suppose you are developing an online banking application. After discussions with your customers, you might come up with the following requirements. This list is a just a sample, and does not include actual numbers.

• security

• 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

Defining the Requirements

Along with identifying requirements, you may need to further define them. Understanding the requirements in detail helps establish the business rules and design guidelines. For example, you might look more closely at who the end users are.

Will users be anonymous, or will they be required to login? In many cases, an application provides introductory web pages that are freely browsable by anonymous users, while other pages would require logging in as a registered users. Registered users might be further classified as regular or premier customers, depending on specified criteria. What are these criteria? For example, a customer may earn premier status by purchasing at least $500 worth of merchandise per month or by maintaining a minimum of $5000 in an account.

Matching Requirements to the Application Model

Designing toward your requirements may affect one or more layers in the application model. Consider the end-user requirements, for example.

In the presentation layer, the application may need to present one set of pages for anonymous users, and another set for registered users. Also, when an anonymous user tries to access a feature reserved for registered users, you might design the application to present a page that explains why the attempt failed, and invite the user to become a member. By the same token, premier customers might have access to some pages that are denied to regular customers.

In the business logic layer, the application must authenticate login attempts against known users, as well as test that users meet the criteria for accessing particular application features.

In the data access layer, the application may need to restrict database access based on the category of end user.

Assembling the Development Team

---

The application model allows different individuals to focus on developing application elements at the same time. This section describes the skills needed from designers and developers for each application layer. The following categories are described:

• The Architect

• Team Roles for the Presentation Layer

• Team Roles for the Business Logic Layer

• Team Roles for the Data and Legacy Access Layer

The composition of the team depends on the size of your group and the scope of the application. For example, not all team roles may be needed, and team members could assume more than one area of responsibility.

The Architect

In component-based application development, one or more individuals must have an overall vision of the application, its control flow, and other interactions. Some organizations call this person the architect. Regardless of the name you use, this individual serves an important role by coordinating the efforts of the various design teams and by helping them think about "the big picture."

Team Roles for the Presentation Layer

The presentation layer is where the user interface is dynamically generated. The following team members are needed:

• Java servlet developers

• JSP developers

• HTML designers

• graphic artists

• client-side JavaScript developers

Servlet developers create the presentation logic, whereas the other roles are for creating the presentation layout.

Java Servlet Developers

Servlets handle page-to-page navigation, session management, and simple input validation. Servlets also tie business logic elements together.

A servlet developer must understand issues related to HTTP requests, security, internationalization, and web statelessness (such as sessions, cookies, and timeouts). For iAS applications, servlets must be written in Java. Servlets are likely to call JSPs, EJBs, and JDBC RowSet objects. Therefore, a servlet developer works closely with the developers of those application elements.

JSP Developers

JSP developers work closely with servlet developers to define the application's presentation screens and storyboards (page navigation). Even on complex development projects, the same person may develop both JSPs and servlets. However, if you design the application so that most of the Java is in servlets rather than in JSPs, a JSP developer need not be proficient in Java.

JSPs are likely to call EJBs and JDBC RowSet objects.

HTML Designers

HTML designers optimize HTML pages. For example, designers might perform any of the following tasks:

• 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.

Graphic Artists

Graphic artists create images that end up as GIFs or JPEGs. These images must be appropriate to the application and must be quick to download. Graphic artists work closely with HTML designers.

Client-Side JavaScript Developers

Client-side JavaScript can be used for several reasons. For example, it can handle simple input validation before passing data to the server, or it can make the user interface more exciting. Client-side JavaScript developers work closely with developers of servlets and JSPs.

Team Roles for the Business Logic Layer

The business logic layer encapsulates business rules and business entities. The following team members are needed:

• Session bean developers

• Entity bean developers

Session Bean Developers

Session beans encapsulate the logic for business processes and business rules. For example, a session bean might be developed to calculate taxes for a billing invoice. Applications usually handle complex business rules that can change frequently (for example, due to new business practices or new government regulations). As a result, an application typically uses more session beans than entity beans, and session beans may need continual revision.

A developer of session beans typically is a domain expert and understands complex, domain-specific logic as well as data validation rules. This developer works closely with developers of servlets and entity beans.

Session beans are likely to call a full range of JDBC interfaces, as well as other EJBs. Applications perform better when session beans are stateless. Here's why. Suppose tax is calculated in a stateful session bean. The application must then access a particular server where that bean's state information resides. If the server happens to be down, then application processing is delayed.

Entity Bean Developers

Entity beans represent persistent objects, such as a row in a database. The role of an entity bean developer is to design an object-oriented view of an organization's business data. Creating this object-oriented view often means mapping database tables into entity beans. For example, the developer might translate a Customer table, Invoice table, and Order table into corresponding customer, invoice, and order objects.

An entity bean developer works with developers of session beans and servlets to ensure that the application provides fast, scalable access to persistent business data.

Entity beans are likely to call a full range of JDBC interfaces. However, entity beans typically do not call other EJBs.

Team Roles for the Data and Legacy Access Layer

In the Data and Legacy Access layer, the main role is the developer of custom extensions. These developers are very likely to use C++, and they typically need to understand issues related to wrapping C++ in Java, such as Java Native Interfaces (JNI).

Extension developers use iPlanet Extension Builder. They are likely to integrate access to the following systems:

• CORBA applications

• mainframe systems

• third-party security systems

After the development team is assembled, the application's user interface can be designed.

Designing the User Interface

---

It is recommended that you design your application from front to back. That is, you should design the user interface before you design or develop EJBs. In this way, you ensure the most efficient application flow.

Begin by planning the navigation storyboards and UI screens. There are many third-party books and online guides that teach web site design. The following list summarizes the questions you may need to resolve:

• 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?

The specific tasks related to creating servlets and JSPs are covered in Part II of this guide.

Guidelines for Effective Development

---

This section lists some of the guidelines to consider when designing and developing a iAS application. This section is merely a summary. For more details, refer to later chapters in this guide.

The guidelines are grouped into the following goals:

• Easing Development

• Maintaining or Reusing Code

• Improving Performance

• Planning for Scalability

Easing Development

• 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.

Maintaining or Reusing Code

• 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.

Improving Performance

• In most cases, deploy servlets and JSPs to iAS rather than to the iPlanet Web Server (iWS). iAS is best if an application is highly transactional, requires failover support to preserve session data, or accesses legacy data. iWS 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.

Planning for Scalability

• 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")