Chapter 1   Migration Overview


This chapter introduces the iPlanet Application Server 6.0 programming model and compares it to both the NAS 4.0 programming model and the NAS 2.1 programming model. It also describes the basics of migrating applications to the new model.

The new iAS 6.0 programming model is for Java applications only. C++ applications continue to use the NAS 2.1 model.

iAS 6.0 is backward compatible with NAS 2.1. applications.
iAS 6.0 is compatible with NAS 4.0 applications with conversion to the J2EE standard. NAS 2.1 applications can run on iAS 6.0 without alteration, but NAS 4.0 applications do need some conversion.

The New J2EE Programming Model

---

The iAS 6.0 Application Server is Java 2 Platform, Enterprise Edition specification version 1.2 (J2EE 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 6.0 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.0 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:

Table 0.1

Programming Tier	NAS 2.1 component	NAS 4.0 component	iAS 6.0 component	Description
Presentation Logic	AppLogic	Java servlet and propietrary 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.0, servlets process incoming requests and orchestrate the response. Business logic is normally offloaded to EJBs, and output is usually offloaded to JSPs.
Presentation Layout (part of Presentation Logic)	HTML template	JavaServer Page (JSP) and propietrary 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 propietrary 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 propietrary 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.0 model.

A Note on Modularity and Flexibility
The terms "normally" and "usually" appear frequently in this document and in the Programmer's Guide with regard to the roles of iAS 6.0 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 an AppLogic, while layout was handled by an HTML template. At run-time, the AppLogic provided output to populate the template.

In the iAS 6.0 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 iAS 6.0 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 iAS 6.0 programming model, data access logic is handled by the JDBC standard set of APIs. The previous APIs are all deprecated in iAS 6.0.

Migration Basics NAS 2.1 to iAS 6.0

---

Migration involves altering an application written for the 2.1 programming model so that it conforms to the 6.0 programming model. There are three approaches to this process, each of which is covered in this document:

• No migration. This approach involves no actions by the developer and depends solely on backward-compatible support by the server. This is an acceptable approach if you do not want to take advantage of the flexibility and power that the new standards-based model provides, although many of the APIs supported in NAS 2.1 are now deprecated and may not be supported in future releases.

  Backward-compatibility is described in .

• Partial migration. In this approach, part of the application conforms to the new programming model, while the rest relies on backward-compatibility. This enables developers to migrate one portion of an application at a time (for example, one level of interaction with a user, or one programming tier) while still retaining the portions of the application that are known and tested.

  iAS 6.0 supports partial migration by providing "glue" between the old components and the new components. This support is described in .

• Complete migration to the new programming model. This approach requires a lot of development resources and involves a full redesign, but it enables the application to take full advantage of the features of the new programming model.

  This approach is described in .

Migration Basics NAS 4.0 to iAS 6.0

---

Migrating to Standard. NAS 4.0 uses Netscape and older Java standards which have been replaced with J2EE 1.2 standards in iAS 6.0. You need to replace deprecated methods and redeploy your applications with the new XML descriptors. Tools are provided to help with the process. See Chapter 4 -Running NAS 4.0 Applications on iAS 6.0.