Chapter 1   Migration Overview


This chapter introduces the iPlanet^TM Application Server 6.5 programming model and compares it to both the NAS 4.0 programming model and the NAS 2.1 programming model.

The new iPlanet Application Server 6.5 programming model is for Java applications only. C++ applications continue to use the NAS 2.1 model. Note the following compatibility issues:

• Due to changes in the compiler used to build iPlanet Application Server 6.5, AppLogics based applications on Solaris will have to be recompiled to run on 6.5.

• iPlanet Application Server 6.5 is backward compatible with NAS 2.1 applications. NAS 2.1 applications can run on iPlanet Application Server 6.5 without code alteration.

• iPlanet Application Server 6.0 is compatible with NAS 4.0 applications with conversion to the J2EE standard. NAS 4.0 applications do require some conversion.

This chapter describes the following topics:

• The New J2EE Programming Model

The New J2EE Programming Model

---

iPlanet Application Server 6.5 is Java 2 Platform, Enterprise Edition (J2EE) specification version 1.2 compliant and is based on standards developed by the Java community, namely: servlets, JavaServer Pages, and Enterprise JavaBeans. This is in contrast to the proprietary AppLogic-based programming model used in NAS 2.1. NAS 4.0 is based on the J2EE programming model but uses earlier versions of the standards.

Application flow is similar between the iPlanet Application Server 6.5 model and the previous 4.0 and 2.1 models. Each user interaction is handled by one (or more) application components that process the inputs, perform business logic functions, interact with a database, and provide an output page that answers the input and sets up the next user interaction. The 6.5 model, like the 4.0 model, is more modular and segregates activities into more discrete components.

The new programming model describes three tiers of application logic, each of which is represented by a set of components or APIs. These tiers are described in the following table:

Programming Tier	NAS 2.1 component	NAS 4.0 component	iPlanet Application Server 6.5 component	Description
Presentation Logic	AppLogic	Java servlet and proprietary standards	Java servlet	Controls the application's interface to the user by processing requests, generating content in response, formatting and delivering that content back to the user. In 6.5, servlets process incoming requests and orchestrate the response. Business logic is normally off-loaded to EJBs, and output is usually off-loaded to JSPs.
Presentation Layout (part of Presentation Logic)	HTML template	JavaServer Page (JSP) and proprietary standards	JavaServer Page (JSP)	Controls the appearance of each page. Part of the presentation logic, usually handled by JavaServer Pages. JSPs are HTML pages that contain embedded Java, and thus are much more versatile and powerful than 2.1 HTML templates.
Business Logic	AppLogic	Enterprise JavaBeans (EJBs) and proprietary standards	Enterprise JavaBeans (EJBs)	Controls business logic. EJBs enable business logic to be persistent across calls, offer improved caching, and are designed to work closely with JDBC for database transactions.
Data Access Logic	DAE	JDBC and proprietary standards	JDBC	Controls database storage and retrieval. The JDBC API is available to all Java components, as are all APIs, though database transactions are usually controlled by EJBs in the 6.5 model.

This section includes the following additional topics:

• Component Modularity and Flexibility

• Presentation Logic and Layout

• Business Logic

• Data Access Logic

Component Modularity and Flexibility

The terms "normally" and "usually" appear frequently in this document and in the Developer's Guide with regard to the roles of iPlanet Application Server 6.5 components. Since servlets, JSPs, and EJBs all reside within the same virtual machine and are all Java objects, they share a flexibility that allows each task to be addressed by more than one component. There are no hard and fast rules specifying which tasks are appropriate for which components. For example, an entire complex application could be written using only JSPs, or only servlets.

However, the components are designed to work together in a modular way, taking advantage of the strengths of each component. For example, it is more cumbersome to perform layout tasks in a servlet, but JSPs (as HTML pages) are highly suitable for layout tasks. Alternatively, presentation logic is compact and elegant in a servlet.

The segregation and order of components describes a powerful application model that runs well in a distributed environment. Choose components that perform the tasks you need, using the programming tiers described here as a guideline.

Presentation Logic and Layout

Presentation logic describes the flow of an application from the perspective of each user interaction: request processing, followed by content generation and delivery. The goal of presentation logic is to create a logical answer to a request, and to prompt for another request. The goal of presentation layout is to display the content of this answer in a predetermined format. Application functions such as user sessions, security and user authentication, and input validation are also handled by the presentation logic.

In short, presentation logic involves everything related to the application's interface with the user.

In the NAS 2.1 programming model, presentation logic was controlled by the AppLogic class, while layout was handled by an HTML template. At run-time, AppLogic objects provided output to populate the template.

In the iPlanet Application Server 6.5 programming model, presentation logic is usually handled by a Java servlet. Layout is usually handled by a JSP. At runtime, the servlet uses a JSP to format the content generated by the business logic.

The two major alternatives to this basic model are as follows:

• Handle all presentation logic and layout for a given interaction in a JSP. This can be an easy way to control an interaction that has no business logic and little to process from the previous interaction. For example, the "front page" for an application often requires no processing at all.

• Handle all presentation logic and layout in a servlet. This can be efficient for interactions that have very little layout. For example, a simple database report might just list the rows retrieved from a database query. It doesn't make sense to incur the overhead of a JSP call when the page can be simply output from a servlet.

Business Logic

Business logic describes the activities that involve the generation of specific content: storing and retrieving data, and performing computations on that data. The goal of business logic is to perform the activities that generate or determine answers to questions posed by the presentation logic.

In short, business logic involves the content provided by and generated for the application.

In the NAS 2.1 programming model, business logic was controlled by the same AppLogic that handled the presentation logic for a given user interaction.

In the iPlanet Application Server 6.5 programming model, business logic is usually handled by one or more Enterprise JavaBeans (EJBs), which control database transactions and encapsulate the results. EJBs are powerful, reusable components that empower applications with a great deal of flexibility, since EJBs can be invoked or inspected from any other object and can be made to be persistent.

One alternative to this model is to handle business logic in the presentation logic (servlets and/or JSPs), much the same way that AppLogics handled business logic. This can be efficient for short, directed business events such as specific directory requests, but this approach lacks the flexibility and power that EJBs bring to the programming model.

Data Access Logic

Data access logic describes transactions with a database or directory server. The goal of data access logic is to provide an interface between an application and the set of data that concerns it. Data access is normally performed as a function of business logic.

In short, data access logic involves the storage and retrieval of the content collected or generated by business logic.

In the NAS 2.1 programming model, data access logic was controlled by calls made from an AppLogic using APIs from several classes and interfaces, including the DataSet, DBDataSet, and DBStoredProcedure classes and the ICallableStmt, IColumn, IDataConn, IDataConnSet, IHierQuery, IHierResultSet, IListDataSet, IPreparedQuery, IQuery, IResultSet, ITable, ITrans, and IValList interfaces.

In the iPlanet Application Server 6.5 programming model, data access logic is handled by the JDBC standard set of APIs. The previous APIs are all deprecated in iPlanet Application Server 6.5.