Chapter 4   J2EE Concepts


This chapter describes the Java 2 Platform, Enterprise Edition and its role in the iPlanet Application Server.

This chapter contains the following sections:

• J2EE Concepts

• J2EE Components

• The J2EE Programming Model

J2EE Concepts

---

J2EE solves the problem of the cost and complexity in developing multi-tiered services that are scalable, highly available, secure and reliable. It achieves this by providing an open standard architecture through the J2EE Platform and the J2EE Application Model. This platform allows developers to focus on the business logic while J2EE handles all the low level details. With J2EE, services are easily enhanced and rapidly deployed, allowing business to quickly react to competitive changes.

J2EE is an open environment for developing and deploying multi-tiered services where thin-client applications invoke business logic that executes on an application server such as the iPlanet Application Server. It comprises of a set of services, application programming interfaces and protocols. The Java programming language the Java Virtual Machine and Java Bean components are the foundation of J2EE.

The Multi-Tiered Model

In the graphic above, the servlet receives the request, validates input, calls the session bean and calls the JSP. The JSP formats the HTML and responds to the client. The session bean validates the request, executes the process, and enforces transactions. The entity beans manage the data.

In a multi tiered model, the first tier is the client and is usually a web browser or stand alone Java application. This invokes the business logic on one or more middle tiers running on dedicated hardware, which in turn accesses data from the Enterprise Information Service on the third tier.

Developing a multi-tiered service requires client applications, business and presentation logic (the applications that get, update and present data) and infrastructure code. The infrastructure is the low level system components that access various databases, system resources and provide security. Infrastructure details are handled by J2EE in iAS so the developer needs only to develop the business and presentation logic.

In the middle tier, business logic is implemented as Enterprise Java Beans components (EJB), while the presentation logic is implemented as Java Server Pages (JSP) and Servlets. Servlets and JSPs allow the separation of the request processing from the presentation logic. The presentation layer of the model allows easy access to the middle-tier business functions. JSP technology allows developers to present dynamically created web pages. Servlets allow developers to create dynamic presentations to users completely in the Java programming language.

J2EE Benefits

• J2EE provides a seamless Java solution across all layers.

• Separation of tasks in the layered platform architecture into business logic away from system services and the user interface, placing business logic it in a middle tier between the two.

• Open set of standards— EJB, JSP, servlets, JDBC, JNDI, RMI make up the J2EE platform.

• Portability— The Java feature of "Write Once, Run Anywhere"(WORA) is in all these technologies. This means that any third party provider can write specially designed components for iAS, reducing the cost of development.

• Scalability— Scalability is the responsibility of the iAS - the application does not need to code for this. Enterprise application systems support high scalability by using a multitier, distributed application architecture with the integrated components.

• Components— The presentation logic, business logic, and data access logic are separated into suitable components and deployed on multiple servers. This enables s an application to take advantage of the high performance of multi threaded and multiprocessing systems.

• Language and API experiences can be leveraged when dealing with another area. For example, experience of writing a Java applet is similar to writing a servlet. Experience of writing a servlet is similar to writing an EJB.

• Sandbox, Garbage Collection, and Exception Handling automatically reduces the problem of one component blocking the operation of the server or another component. For example, servlets allow you to plug custom code into a Web server as a plug- in or extension library would. The difference however, is that servlets have garbage collection and exception handling abilities, so a problem in a servlet should not affect the server operation. EJBs function in the same way and can be deployed on a database or application server.

J2EE Components

Transaction management, life- cycle management, and resource pooling are built into the J2EE platform and provided automatically to the components it supports. Component and application developers are free to focus on specifics such as business logic and user interfaces. The J2EE application model encapsulates the layers of functionality in specific types of components. Business logic is encapsulated in Enterprise JavaBean (EJB) components. Client interaction can be presented through the following:

• Plain HTML Web pages

• Web pages powered by Java applets

• Java Servlets API

• JavaServer Pages technology

• Stand- alone Java applications

Components communicate transparently using various standards, including HTML, XML, HTTP, SSL, RMI, IIOP, and others.

J2EE is made of different components;

• Servlets— an efficient platform- independent replacement for CGI scripts responding to client requests.

• JavaServer Pages (JSP)— a type of server- side scripting, which can dynamically generate Web pages.

• Enterprise JavaBeans (EJB)— server- side session management, business logic encapsulating and abstractions for accessing persistent data.

• Java Database Connectivity (JDBC)— an API that describes a standard Java library for accessing data sources.

• Transaction Support— declarative transactions for components where transactions can span components and processes.

• Java Naming and Directory Interface (JNDI)— an abstract interface to name binding and directory search services.

• Remote Method Invocation (RM/IIOP)— an enabling technology for distributed object communication.

• CORBA Compatible— CORBA complements Java by providing a distributed objects framework, services to support that framework and interoperability with other languages.

Servlets

In J2EE, servlets manage the presentation logic of an application by acting as a central dispatcher for applications by processing form input, invoking business logic components by accessing Enterprise JavaBeans, and formatting page output using JSPs. Servlets control the application's flow from one user interaction to the next by generating content in response to a request from a user.

Servlets are used to handle request and response from browser clients. Servlets are like applets except they run on a server instead of a client.

Java Server Pages

JavaServer Pages (JSPs) are the presentation layout mechanism. They are browser pages in HTML or XML. They can optionally contain Java code, which enables them to perform complex processing, conditionalize output, and communicate with other objects in your application. JSPs in iPlanet Application Server 6.0 are based on the JSP 1.1 specification

In iPlanet Application Server applications, you use JSPs as the individual pages that make up your application. You can call a JSP from a servlet to handle the output from a user interaction, or, since JSPs have the same access to the application environment as any other application components, you can use a JSP as a destination from an interaction.

JSPs are compiled into servlets, either when installed or the first time they are called. This makes JSPs available to the application environment as standard objects and enables them to be called from a client using a URL.

You can think of servlets and JSPs as opposite sides of the same coin: each can perform the tasks of the other. However, because JSPs are written as HTML files, with embedded Java code, they are best suited for layout tasks. Servlets are best suited as central dispatchers for incoming requests.JavaServer Pages (JSPs).

Enterprise Java Beans

Enterprise JavaBeans (EJBs) are applications. If servlets act as the central dispatcher for your application and handle presentation logic, EJBs do the bulk of your application's actual data and rules processing but provide no presentation or visible user- interface services. EJBs enable you to partition your business logic, rules, and objects into discrete, modular, and scalable units. Each EJB encapsulates one or more application tasks or application objects, including data structures and the methods that operate on them. Typically, EJBs also take parameters and send back return values. EJBs always work within the context of a "container," which serves as a link between the EJBs and the server that hosts them. As an iPlanet Application Server developer, you need not worry about the container for your EJBs. The iPlanet Application Server software environment provides the container. This container provides all the standard container services denoted in the EJB 1.1 specification. It also provides additional services such as stateful session bean failover. In fact, the container can handle all remote access, security, concurrency, transaction control, and database access. Because the actual implementation details are part of the container, and there is a standard, prescribed interface between a container and its EJBs, the bean developer is freed from having to know or handle platform- specific implementation details. Instead, the enterprise bean developer can create generic, task- focused EJBs for use with any vendor's products that support the EJB Standard.

Session Beans and Entity Beans

There are two kinds of EJBs: entity and session. Each of these bean types is used differently in a server application. An EJB can be an object that represents a stateless service, an object that represents a session with a particular client (and which automatically maintains state across multiple client-invoked methods), or can be a persistent entity object possibly shared among multiple clients. A session bean implements business logic. All functionality for remote access, security, concurrency, and transactions is provided by the EJB container. A session EJB is a private resource used only by the client that creates it. More information on session beans can be found in the EJB 1.1 specification.

Entity EJBs

Entity beans most commonly represent persistent data. This data is maintained directly in a database, or accessed through a back-end application as an object. A simple example of an Entity Bean would be one that is defined to represent a single row in a database table, and where each instance of the Bean represents a specific row. A more complex example would be an Entity Bean designed to represent complicated views of joined tables in a database where each instance of the Bean would represent a single customer's shopping cart contents.

Unlike Session Beans, Entity Bean instances can be accessed simultaneously by multiple clients. The container, is responsible for synchronizing the instance's state by using transactions. This delegation of responsibility to the container, means the Bean developer does not need to worry about concurrent access to methods from multiple transactions.

The persistence of an Entity Bean can either be managed by the bean itself, or by the bean's container. When the Entity Bean manages it's own persistence, it's called Bean-managed persistence. When the bean delegates this function to the container, it's called container-managed persistence (CMP).

Bean-managed Persistence. The bean developer must implement persistence code (such as JDBC calls) directly in the EJB class methods, if the bean is to manage it's own persistence. The possible downside of this implementation is the loss of portability, if a proprietary interface is used, and also the risk of tying the bean to a specific database.

Container-managed Persistence (CMP). The container provider uses the iPlanet Application Server Deployment Tool (iASDT) to generate the bean code to implement the container persistence process. The container manages, transparently to the bean, the persistence state. The bean developer does not need to implement any data access code in the bean's methods. Not only is this method simpler for the bean developer to implement, but it makes the bean fully portable, without any ties to a specific database.

Finally, any number of entity beans can be installed in a container. The container implements a home interface for each entity bean. The home interface enables a client to create, look up, and remove entity objects. A client can look up an entity bean's home interface through the Java Naming and Directory Interface (JNDI).

The J2EE Programming Model

The iPlanet Application Server 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, including servlets, JavaServer Pages, and Enterprise JavaBeans. iPlanet Application Server 6.0 programming model is for Java applications only. C++ applications continue to use the NAS 2.1 model.

iPlanet Application Server 6.0 is backward compatible with NAS 2.1. applications. NAS 2.1 applications can run on iPlanet Application Server 6.0 without code alteration. NAS 4.0 applications are compatible with conversion to the J2EE standard and do need some conversion.

Application flow is similar between the iPlanet Application Server version 6.0 model and the previous version 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 new programming model describes three tiers of application logic, each of which is represented by a set of components or APIs.

Programming Tier	NAS 2.1 component	NAS 4.0 component	iAS 6.0 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.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 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.0 model.

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.

Rich Clients

The Rich Client is a stand-alone Java program that can directly access EJBs deployed on iPlanet Application Server. Traditionally, clients communicated with iPlanet Application Server through the web-path, i.e. by speaking HTTP to server components such as JSPs and Servlets which in turn had access to EJBs within the context of the server. The J2EE v1.2 specification, however, requires that stand-alone clients be able to talk to iPlanet Application Server using the RMI-IIOP standard. Chapter 9 of the J2EE v1.2 specification also requires that these stand-alone clients operate within the context of an Application Client Container (ACC) that isolates server-specific issues, leaving the clients completely portable. Through its Rich Client infrastructure, iPlanet Application Server allows Java clients to directly access EJBs on iPlanet Application Server. These clients could operate within an ACC that ships with iPlanet Application Server as required by the J2EE ACC specification or more straight forward direct access (non ACC path) the way Java programmers are used to writing them.

The diagram below is a schematic representation of the iPlanet Application Server architecture and illustrates the difference between the Rich Client and web paths. While browser clients communicate with iPlanet Application Server using HTTP through a Web Server, Rich Clients circumvent the Web server and directly access EJBs as RMI-IIOP clients. Failover support is also provided for entity bean failover in case of a Corba Executive Service (CXS) crash

The Rich Client is a first-tier program that executes in its own Java Virtual Machine (JVM), possibly in an ACC. Deploying the Rich Client requires the specification of deployment descriptors using XML.

Container Managed Persistence

If you want the EJB container to manage the storing of entity bean variables to an underlying resource manager, then the iPlanet Application Server Deployment Tool is used to configure the EJB container with container managed persistence (CMP) settings.

iPlanet Application Server implements CMP with:

• Support for the J2EE v 1.2 specification CMP model.

• Support of multiple pluggable pooling and persistence managers on a per bean basis.

• Provide user with a deployment tool (iASDT) to perform the object relational (O/R) mapping and create the separate CMP deployment descriptor XML files.

• Support for Commit Options B and C

• Support for sophisticated custom finder methods

• Pluggable Persistence Managers

Pluggable persistence managers allow users to set the persistence policies for a bean at deployment time. This flexible framework allows a customer to use a third party persistence manager of choice at deployment time. Factory classes for persistence manager can be set in the bean's deployment descriptor XML file. The classes specified in these fields will be used by the container to create either zero or one persistence managers for a bean.

iPlanet Application Server also supports sophisticated Object to Relational (OR) mapping middleware. CocoBase, from Thought, Inc., provides a dynamic repository based Object to Relational mapping tool which delivers CMP and Bean Managed Persistence.

RMI-IIOP

RMI over IIOP combines the best features of RMI with the best features of CORBA. Like RMI, RMI over IIOP speeds distributed application development by allowing developers to work completely in the Java programming language. When using RMI over IIOP to produce Java technology-based distributed applications, there is no separate Interface Definition Language (IDL) or mapping to learn. Like RMI, RMI over IIOP provides flexibility by allowing developers to pass any serializable Java object (Objects By Value) between application components. Like CORBA, RMI over IIOP is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group. Like CORBA, RMI over IIOP uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, Smalltalk, and other CORBA supported languages to communicate with components running on the Java platform.

Using JDBC for Database Access

In iAS, Enterprise JavaBeans (EJBs) support database access primarily through the JDBC API. iPlanet Application Server supports all of JDBC 2.0 API including result set enhancements, batch updates, distributed transactions, row sets, and JNDI support for datasource name lookups.

While this section assumes familiarity with JDBC 2.0, it also describes specific implementation issues that may have programming ramifications. For example, the JDBC specifications do not make it clear what constitute JDBC resources. In the specifications, some JDBC statements—such as any of the Connection class methods that close database connections—release resources without specifying exactly what those resources are.

JDBC Overview

JDBC is a set of Java classes and methods that let you embed database calls in your server applications. That's all you need to know in order to start using JDBC in your server applications.

More specifically, JDBC is a set of interfaces that every server vendor, such as iPlanet, must implement according to the JDBC specifications. iPlanet Application Server provides a JDBC type 2 driver which supports a variety of database back-ends. This driver processes the JDBC statements in your applications and routes the SQL arguments they contain to your database engines.