|Previous Contents Index Next|
|iPlanet Application Server 6.5 SP1, Enterprise Edition Developer's Guide|
|Updated: November 25, 2002|
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:
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:
- 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 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 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.
Properly designed HTML pages provide:
- Dynamically generated page appearances that are servlet or JSP dispatched.
The Business Logic Layer
The business logic layer typically contains deployed entities that encapsulate business rules and other business functions in:
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 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:
For more information about UIF, see the iPlanet Unified Integration Framework Developer's Guide and the release notes at the following URL:
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
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 UIF-based connectors to access legacy data.
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.
- 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.
To plan an application to easily scale as customer demand increases:
- Design an application to run in a multi-machine server farm environment.
There are six major factors to keep in mind when modularizing your J2EE Applications:
Five packaging samples (A through E) provide examples of the packaging concepts explained here. For an overview of these samples, see:
For more information about packaging applications, see Chapter 11 "Packaging for Deployment."
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.
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.
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.
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.
The following general formulas should be followed when packaging modules and applications:
Type of Development Group
Teams in Group
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
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.
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:
- 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.
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated November 25, 2002