Chapter 1   Developing Applications


This chapter summarizes the iPlanet ^TM 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 servlet or 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

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

For more information, see Chapter 4 "Introducing Enterprise JavaBeans".

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.

For more information, see Chapter 4 "Introducing Enterprise JavaBeans",

Message Driven Beans

Message Driven Beans are similar to Session and Entity Beans in that they support the framework provided by an Enterprise JavaBean. However, message-driven beans are also Java Messaging Service (JMS) listeners and perform tasks based upon the request it receives from a client in the form of JMS Messages.

Unlike Session and Entity Beans, message-driven beans process message queues asynchronously, thereby making better use of server resources. The message-driven bean can handle many client requests simultaneously and therefore, does not create message queue bottlenecks.

For more information, see Chapter 7 "Using Message Driven Beans".

The Data Access Layer

In the Data Access layer, custom connectors work with the iPlanet ^TM 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 ^TM 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

• Modularizing Applications

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 ^TM Application Server:

• In most cases, deploy servlets and JSPs to the iPlanet ^TM Application Server rather than to the iPlanet Web Server. iPlanet ^TM 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.

Modularizing Applications

There are six major factors to keep in mind when modularizing your J2EE Applications:

• Functional Isolation

• Reusable Code

• Prepackaged Components

• Unique Names

• Shared Framework Classes

• Session and Security Issues

Five packaging samples (A through E) provide examples of the packaging concepts explained here. For an overview of these samples, see:

http://developer.iplanet.com/appserver/samples/pkging/docs/index.html

For more information about packaging applications, see Chapter 11 "Packaging for Deployment."

Functional Isolation

Each module should do one thing and one thing only. For example, in a payroll system, one enterprise bean should access the 401k accounts while a separate bean accesses the salary database. This functional isolation of tasks leads to the physical isolation of business logic into two separate beans. If separate development teams create these beans, each team should develop its own EJB JAR package.

Scenario 1
Assume that the UI development team works with both of the bean development teams. In this case, the UI development team should package its servlets, JSPs, and static files into one WAR file. For example:

payroll system EAR file =    payroll EJB jar
         + 401k ejb JAR
         + 1 common war from the UI team

This isolation of functionality within an EAR file does not mean that modules cannot interact with each other. The beans (in separate EJB JAR files) can call business methods from each other. This packaging is illustrated in Sample A.

Scenario 2
Assume that each bean development team has its own UI development team. If this is the case, then each web development team should package its servlets, JSPs, and static files into separate WAR files. For example:

payroll system EAR file =    payroll EJB jar
         + 401k ejb JAR
         + 1 payroll UI team's war + 1 401k UI team's war

With this setup, the components in each WAR file can access components from the other WAR file. This packaging is illustrated in Sample B.

Scenario 3
Assume that each module accesses functions from a shared library. If several modules access methods from this library, then this library needs to be added to one (and only one) module of the EAR file. For an example of this, see Sample C.

Packaging Formulas
The following general formulas should be followed when packaging modules and applications:

Table 1-1    Packaging formulas

Type of Development Group	Teams in Group	Modularizing Scheme
Small workgroup	1 web dev team + 1 ejb dev team	1 EAR = 1 ejb + 1 war
Enterprise workgroup	2 ejb dev teams + 1 web dev team + 1 component	1 EAR = 2 ejb + 1 war + 1 standalone module

Reusable Code

Reusable components are the primary reason for packaging and deploying modules rather than applications. If the code developed by one team of developers is a reusable component that may be accessed by several applications (different EAR files), then that code should be packaged and registered as a module using the following command:

iasdeploy deploymodule module_name

Prepackaged Components

If you do not want to create your application from scratch, you can use prepackaged components. Today's leading J2EE component vendors offer many prepackaged components that provide modules for a whole host of services. Their goal is to provide up to 60% of the standard components needed for an application. With iPlanet Application Server, you can easily package applications that make use of these readily available components.

Unique Names

It is important for each module, application, and EJB to have its own unique name. You may want to establish some naming conventions that will help you ensure that no two entities are assigned the same name. For example, one way to guarantee that all modules have unique names is to use the application name as a prefix to the module name. Using this convention, pkgingWar.war would be an ideal name for the WAR module in the application pkging.ear.

JNDI lookup names for EJBs must also be unique. Here too, establishing a consistent naming convention may help. For example, appending the application name and the module name to the EJB name would be one way to guarantee unique names. In this case, mycompany.pkging.pkgingEJB.MyEJB would be the JNDI name for an EJB in the module pkgingEJB.jar, which is packaged in the application pkging.ear.

Shared Framework Classes

Sometimes several applications need to access a single modular library -- for example the LDAP SDK, the Cocobase CMP runtime, and so on. In such cases, including the library in each J2EE application is not a good idea for two reasons:

• Library size: Most framework libraries are large, so including them in an application increases the size of the packaged application.

• Different versions: Because a separate class loader loads each application, several copies of the framework classes exist during runtime.

One way to include this library in the iPlanet Application Server runtime environment is to add it to the System Classpath (in the iasenv.ksh script under the install_dir/ias/env directory and in the iPlanet Application Server registry on NT). This way the framework is loaded by the System Classloader. For more information about the System Classloader, see "The Classloader Hierarchy."

Session and Security Issues

If session sharing is a requirement, all of the components that need to access a session should be contained in the same application. Session sharing across application boundaries is not supported in iPlanet Application Server and is a violation of the J2EE specification.

If an HTTP session needs to be shared between two WAR files in an EAR file, the session should be marked "distributed" in the Deployment Descriptor. Sample B illustrates this.

You should not allow unauthorized runtime access to classes, EJBs, and other resources. A module should only contain classes that are permitted to access other resources included in the module. In addition, you should use the standard J2EE declarative security (see Chapter 13 "Writing Secure Applications") for sensitive tasks.