Chapter 1   Developing Applications


This chapter summarizes the iPlanet Application Server application design process and offers effective development guidelines.

This chapter contains the following sections:

• Application Requirements

• About the Application Programming Model

• Effective iPlanet Application Guidelines

Application Requirements

---

When developing an iPlanet Application Server application, start by identifying the application requirements. Typically, this means developing a distributed application as a widely deployable application that is fast and secure, and that can reliably handle additional requests as new users are added.

The iPlanet Application Server meets these needs because it supports the J2EE APIs as well as a set of pre-existing high performance features. For example, for an online banking application, you can deliver:

• High performance

• Scalability

• Rapid deployment

• Security

• Rapid deployment of specific features; for example, account transfers, account reporting, online trades, special offers to qualified customers

• Management and administration of different types of end users; for example, individuals, corporations, or internal users

• Internal reporting

• Enterprise Information System (EIS) connectivity; that provides access to information stored in legacy databases

About the Application Programming Model

---

A distributed application model allows different individual application areas to focus on different functional elements, thereby improving performance. For instance, designing security requirements may affect one or more application model layers.

In the presentation layer, you may need to check a user's identity so your application could present one set of pages for anonymous users and another set for registered users. Additionally, the application may present a page explaining why the attempt to use a restricted feature 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 end user category.

The Presentation Layer

The presentation layer is where the user interface is dynamically generated. An application may require the following application elements:

• Servlets

• JSPs

• HTML pages

• Client side JavaScript elements

Servlets

Servlets handle the application's presentation logic. Servlets are the page-to-page navigation dispatchers, and they also provide session management and simple input validation. Servlets tie business logic elements together.

A servlet developer must understand programming issues related to HTTP requests, security, internationalization, and web statelessness (such as sessions, cookies, and time-outs). For an iPlanet Application Server application, servlets must be written in Java. Servlets are likely to call JSPs, EJBs, and JDBC objects. Therefore, a servlet developer works closely with the application element developers.

JSPs

JSPs handle most application display tasks, and they work in conjunction with servlets to define the application's presentation screens and page navigation. JSPs are likely to call EJBs and JDBC objects. The EJBs typically encapsulate business logic functionality. As such, they carry out calculations and other repetitively requested tasks. JDBC objects are used to connect to databases, make queries, and return query results.

HTML Pages

Properly designed HTML pages provide:

• Uniform appearance across different browsers.

• Efficient HTML loading across slow modem connections.

• Dynamically generated page appearances that are JSP dispatched.

Client-Side JavaScript

Client-side JavaScript can also be used to handle such things as simple input validation before passing data to the server, or to make the user interface more exciting. Client-side JavaScript developers work closely with servlet and JSP developers.

The Business Logic Layer

The business logic layer typically contains deployed entities that encapsulate business rules and other business functions in:

• Session beans

• Entity beans

Session Beans

Session beans encapsulate the business processes and rules logic. For example, a session bean could calculate taxes for a billing invoice. When there are complex business rules that change frequently (for example, due to new business practices or new government regulations), an application typically uses more session beans than entity beans, and session beans may need continual revision.

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 taxes are calculated in a stateful session bean. The application must access a specific server where the bean's state information resides. If the server happens to be down the application processing is delayed.

Entity Beans

Entity beans represent persistent objects, such as a database row. Entity beans are likely to call a full range of JDBC interfaces. However, entity beans typically do not call other EJBs. The entity bean developer's role 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 session bean and servlet developers to ensure that the application provides fast, scalable access to persistent business data.

The Data Access Layer

In the Data Access layer, custom connectors work with the iPlanet Application Server Unified Integration Framework (UIF) to enable communication with legacy EISs, such as IBM's CICS.

Connector developers are most likely to use C++ and typically need to understand issues related to wrapping C++ in Java, such as Java Native Interfaces (JNI), as well as UIF.

UIF is an API framework, that enables the application server to pass information to an EIS database. These developers are likely to integrate access to the following systems:

• CORBA applications

• Mainframe systems

• Third-party security systems

For more information about UIF, see the iPlanet Unified Integration Framework Developer's Guide and the release notes at the following URL:

http://docs.iplanet.com/docs/manuals/ias.html#uifsp1

Effective iPlanet Application Guidelines

---

This section lists guidelines to consider when designing and developing an iPlanet Application Server application, and is merely a summary. For more details, refer to later chapters in this guide.

The guidelines are grouped into the following goals:

• Presenting Data with Servlets and JSPs

• Creating Reusable Application Code

• Improving Performance

• Scalability Planning

Presenting Data with Servlets and JSPs

Servlets are often used for presentation logic and serve as central dispatchers of user input and data presentation. JSPs are used to dynamically generate the presentation layout. Both servlets and JSPs can be used to conditionally generate different pages.

If the page layout is its main feature and there is little or no processing involved to generate the page, it may be easier to use a JSP alone for the interaction.

For example, after an Online Bookstore application authenticates a user, it provides a boilerplate portal front page for the user to choose one of several tasks, including a book search, purchase selected items, and so on. Since this portal conducts little or no processing, it can be implemented solely as a JSP.

Think of JSPs and servlets as opposite sides of the same coin. Each can perform all the tasks of the other, but each is designed to excel at one task at the expense of the other. The strength of servlets is in processing and adaptability, and since they are Java files you can take advantage of integrated development environments while you are writing them. However, performing HTML output from them involves many cumbersome println statements. Conversely, JSPs excel at layout tasks because they are simply HTML files and can be edited with HTML editors, though performing computational or processing tasks with them can be awkward.

For more information on JSPs, see Chapter 3 "Presenting Application Pages with JavaServer Pages."

Creating Reusable Application Code

Aside from using good object-oriented design principles, there are several things to consider when developing an application to maximize reusability, including the following tips:

• Use relative paths and URLs so links remain valid if the code tree moves.

• Minimize Java in 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 hard-coded strings such as the datasource names, 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 UIF-based connectors to access legacy data.

Improving Performance

Here are several tips to improve your application's performance when it is deployed on an iPlanet Application Server:

• In most cases, deploy servlets and JSPs to the iPlanet Application Server rather than to the iPlanet Web Server. iPlanet Application Server is best if an application is highly transactional, requires failover support to preserve session data, or accesses legacy data. The iPlanet Web Server is useful if an application is mostly stateless, read-only, and non-transactional.

• Use entity beans and stateless session beans; design for co-location to avoid time intensive 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 information rows, 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 Java performance.

Scalability Planning

To plan an application to easily scale as customer demand increases:

• Develop your application so that it stores scaling or serializing information in HttpSession objects that are configured for distribution.

• Avoid using global variables.

• Design an application to run in a multi-machine server farm environment.