Designing Applications


This chapter describes the various parts of the iPlanet Application Server application, as well as important elements of the development process, including choosing a programming language.

The following topics are included in this chapter:

• Parts of an iPlanet Application Server Application

• Questions to Ask Before You Start

• Designing the Components of the Application

Parts of an iPlanet Application Server Application

---

An iPlanet Application Server application is made up of several components, which fall into three categories:

• Database tier

• Client tier

• Server tier

Database Tier
The foundation of any iPlanet Application Server application is the database. It is vital that the database portion of the application be designed so that it lends itself to working with the application code.

Client Tier
Assuming the application uses HTML as its client strategy, then the user interface is made up of HTML Pages, which are stored in the server tier.Server Tier

The following application components reside in the server tier. Not all of these components are used in every application.

• AppLogic Objects

• HTML Pages

• Templates

• Query Files

• Other Code

The rest of this section gives a brief description of the client- and server-tier application components. The database tier is outside the scope of this documentation.

AppLogic Objects

An AppLogic object is a set of programming instructions that accomplish a well-defined, modular task within the application. AppLogic objects run on the iPlanet Application Server and are managed and hosted by it. Typically, an application includes several to many AppLogics, which can be deployed across many servers. These AppLogics provide some or all of the procedural, or logic, portion of the application.

Each AppLogic object is derived, directly or indirectly, from the GXAppLogic class in the iPlanet Application Server Foundation Class Library. AppLogics can be written in Java or C++. In this manual, it is assumed that you are using C++.

For more information about AppLogics, see

HTML Pages

HTML pages are used to provide the user interface for Web-browser based applications. An HTML page might include the following items:

• Input fields for the user to provide information.

• A Submit button for the user to request action.

• An AppLogic call (not visible to the user) that tells iPlanet Application Server which AppLogic object to run to perform the requested action when the user clicks a Submit button.

• If the page was generated dynamically using an HTML template, it will also contain live data.

Templates

A template is a text file that can be merged with dynamic data to produce formatted output. Templates include special GX markup tags, which specify how to merge the data with the page.

For more information, see

Query Files

A query file is a file with a .gxq extension that contains the specifications for one or more database commands, such as queries or any other SQL command. Query files are generated automatically when you use the Query Designer to build queries. You can also write query files yourself using any text editor.

For more information, see

Other Code

In addition to AppLogic objects, your application can include other code to perform various tasks. For example, you might have a file that contains helper functions such as data conversions that are specific to your application. You can also subclass from classes in the iPlanet Application Server Foundation Class Library if you want to modify or add to the default behavior provided.

Questions to Ask Before You Start

---

During the planning phase of the project, it is advisable to ask the following questions and make the following decisions. Make sure everyone concerned with the project is in agreement about the decisions that have been made.

• What is the purpose of the application? What result is desired when people start using it?

• How many users are expected?.

• Will the users be anonymous, or closely tracked and secured? A website that gives travel tips probably has thousands of anonymous users. In contrast, an online banking application probably requires users to log in to a secured session before accessing certain parts of the application, such as the screen that is used to transfer funds between accounts.

• Will you use iPlanet Application Server sessions to track the users? Which types of sessions, secure or non-secured? The answers to these questions affect how you use sessions and manage users. Even if security is not an issue, you might use sessions for other purposes, such as to record a user's preferences as they move through the application. If you want to require the user to log in, sessions provide the best security mechanism.

• If using secured sessions, you must decide which AppLogic objects in the application are accessible to all users, and which are accessible only to users who have logged in with a password. A single application is likely to contain both secured and unsecured AppLogics. For example, the login screen is, of necessity, available to any user, as are the AppLogics that display it and handle the user's login request.

• Is there an existing application that will be replaced or augmented by the iPlanet Application Server application? Which features of that application are to be kept, and which discarded? Will the legacy code be incorporated into the application? These answers lead into decisions about whether to code the application in C++ or use Java native calls.

• Are there any particular features that are desired in the application in order to showcase a company's products or promote a certain development approach? These features are in addition to those that are dictated by the practical purpose of the application.

• What strategy will you use to keep track of the parts of the application? A pictorial flowchart is useful for visualizing the HTML templates, AppLogics, and other components of an application. Once development is underway, a good source control system is advisable if the application is of any size or if several developers are involved.

• Lastly, and most importantly: What components, such as AppLogics and templates, are needed in the application? Considerations such as reusability and time available for development should be weighed when answering this question. These considerations are addressed in detail in

Designing the Components of the Application

---

This section describes some of the considerations and techniques you can use when deciding how to design the various components in an application.

User Interface Design

It is advisable to design the user interface of the application first. If your development team includes interface (UI) specialists, be sure to include them early in the design process. Changes they make to the screens can have major effects on how the application must be designed. For example, the use of frames in a Web browser can have a profound effect on the business logic layout of an application.

HTML Interface Design

In an HTML-based application, you need to inform the UI designer of which GX tags and database fields will be available for them to use in the HTML pages and templates. GX tags are placeholders for the dynamic data that is merged with the templates at runtime to create live HTML pages. These are the basics of communication between the code and the templates. As long as the database fields and GX tags match what is expected in the code, the UI expert can design the appearance and other features of the UI with a free hand.

Impact of Caching on the User Interface

The capability of iPlanet Application Server to cache AppLogic results can dramatically improve performance. A cache is a fast-access area in the computer's memory. The first time an AppLogic runs, it can store its results in the cache. When the iPlanet Application Server receives additional requests for the same AppLogic, instead of running the AppLogic again, the iPlanet Application Server returns the results directly from the cache.

Each AppLogic has one result cache. The cache can contain multiple results, which are produced by running the AppLogic with different input parameter values. When you set up caching in code, you specify which input parameters are significant in deciding when to cache a result. For example, you might want to cache sales reports for certain products and not others, so you would use the input parameter containing the product code to control caching.

Plan on caching early in the design process, because its use affects how you design the client side of the application. All the criteria needed for caching must be present in the input parameters of the AppLogic request. For example, when the clients are Web browsers, this means the caching criteria must be present as fields on an HTML form, or as arguments in the URL that calls the AppLogic.

For more information, see

Combining or Splitting Application Components

When designing your application, you will find that there are certain approaches that can help you find the optimum way to divide up the functionality. You will need to make some decisions about the size and number of AppLogics, templates, and other components in the application.

The application will fall somewhere on a continuum from a very large number of components, each of which performs an extremely limited task, to a very small number of components, each of which can perform many tasks. Where exactly the application falls in this spectrum depends on your development needs and goals.

The following considerations affect your decision to combine or split application components:

• Redundancy

• Reusability

• Caching

• Performance

Redundancy

If you use a flowchart to represent a user's navigation through an application, you will find it helpful in making decisions about combining functionality. Flowcharts are especially useful for spotting redundant code or screens.

For example, if the flowchart shows two screens that are almost identical in an HTML-based application, it may be advisable to combine the functionality. You could write one AppLogic object that uses different templates depending on runtime conditions. You could also write one HTML template which can vary its output. The template could be populated with different data, or could contain conditional portions of HTML.

Similarly, a flowchart can help you spot redundant AppLogics. Deciding when to group functionality into one AppLogic, and when to split one AppLogic into several, is an important design decision. By grouping similar functionality into one AppLogic that takes slightly different actions, perhaps depending on an input parameter, you reduce the amount of coding and development time. By using fewer AppLogics, you produce a simpler design and a more sleek deployment profile.

For example, consider an application that allows the user to work with employee records. The user can either add a new employee or modify the data that is already stored for an existing employee. The forms displayed to the user for both operations are similar, with fields for the employee name, address, and so on. The only difference between the two screens is that in the case of modifying data, the fields are already filled in with the existing data, and the screen prompts and action button are labeled Modify instead of Add.

If you drew a flowchart of this application, as shown in the following illustration, it would be apparent that the HTML templates and AppLogics required by these two operations are redundant:

More efficiently, you could write a single AppLogic to be executed in response to the main menu, and a single HTML template using conditional GX markup tags to produce slightly different screens. The AppLogic would take an input parameter to indicate whether the user wanted to display the Add Employee screen or the Modify Employee screen. This new design would look like the following illustration:

Alternatively, if updating a record and inserting a new record involve radically different business logic, you might keep separate AppLogics for inserting and updating records. A new employee is likely to require more business rules or processes. However, you could still combine the screen display AppLogic and the HTML templates.

Reusability

If a particular task is performed repeatedly and is called from several parts of the application, it is preferable to divide this code into a separate, reusable component.

For example, suppose your application contains a Main Menu screen which is displayed after each user-selected operation is complete. Rather than write code to display the Main Menu at the end of every AppLogic in the application, it is preferable to create a Main Menu AppLogic that performs only the single task of displaying this screen. The other AppLogics can then call the Main Menu AppLogic whenever it is necessary to display the Main Menu.

You can also reuse a component in several applications. If you consider this when designing the first application in a suite, it will make the task of developing the subsequent applications easier. For example, you might want to create separate HTML templates that contain standard look-and-feel elements of the user interface.

The HTML template SuccessMessage.html in the Online Bank sample application is an example of a reusable component. This template is called throughout the application code whenever it is necessary to display an informational message to the user.

Caching

For the purposes of caching AppLogic results, it is best to keep functionality in separate AppLogics. If you group too much functionality into too few AppLogics, you might encounter more difficulty in caching results. Because caching results can greatly increase performance, it is important to consider caching during the application design phase.

When an AppLogic performs one task and returns one type of result, it is relatively simple to set up the caching criteria. If the AppLogic is capable of returning multiple types of results, the caching criteria can become complex. It is likely your cache criteria will require more input parameters to the AppLogic, and it may be difficult to predict exactly how caching will occur.

For reasons of resource usage, it is advisable not to keep too much data in a single AppLogic cache. Therefore, caching five or six types of results in one cache for a multi-purpose AppLogic might have a negative impact. In addition, the iPlanet Application Server keeps a least-recently-used list of the cached items, and if too many items are cached, some might be removed from the end of the list.

For more information, see

Deployment and Partitioning

Deployment and partitioning considerations affect the desired granularity of code. For example, if the task of displaying the Main Menu is performed from many parts of your code, you might want to put that functionality into a single AppLogic, not only for reusability, but also so that you can distribute the code to every machine in the installation. In this way, the code will have maximum availability and the performance of the application will be improved.

In the Online Bank sample application, the AppLogic objects OBLogin, ShowMenuPage, and OBLogout are good candidates for widespread distribution of this kind.

Performance

Increasing the number of AppLogics does not have a significant negative effect on application performance. The iPlanet Application Server can quickly find the correct AppLogic for any given request, even if there are many AppLogics in the application. As noted earlier, increasing the number of AppLogics can actually improve performance by making the code more readily available and improving the ease of caching.

At a Glance

The following table summarizes the reasons for combining functionality into fewer components or splitting it into more components:

Goal	Action
Reduce redundant code or templates	Combine
Make best use of limited development time	Combine
Reuse components within application or throughout suite of applications	Split
Maximize granularity for caching AppLogic results	Split
Increase availability of components when application is deployed	Split
Optimize performance	Split

Designing an AppLogic Base Class

Instead of collapsing functionality into fewer AppLogics, another strategy to reduce redundant coding is to create a custom AppLogic base class, derived from the GXAppLogic class in the iPlanet Application Server Foundation Class Library. The custom base class contains helper methods to perform the routine tasks that are specific to your application. Derive all the other AppLogics in the application from this base class, rather than directly from the GXAppLogic class. This will give you a head start and reduce repetitive coding.

The following list shows a few of the tasks you might perform in a custom AppLogic base class:

• Check input parameters.

  For more information, see

• Provide standard, application-specific data conversion helper functions.

• Verify the session ID.

  For more information, see

• Set up part of the template map.

  For more information, see

• Produce common presentation elements, such as corporate banners.

• Provide debugging helper functions, such as to log the current date and time and the last executed AppLogic.

The Online Bank sample application uses a customized AppLogic base class called OBBaseAppLogic. This class contains methods to create a user session, initiate contact with the database, handle certain types of errors, and show a success message to the user. For more information, see

Designing a Login AppLogic Object

A typical way to design a secured application is to write one AppLogic object that is the main entry point to the application. This AppLogic responds to the user's first request. The AppLogic gathers and authenticates the user's login ID and password. If the user is authorized to run the application, the login AppLogic creates a session and assigns a session ID to the user's session with the application.

The user then continues to make requests and run other AppLogics in the application. Each subsequent AppLogic checks for the session ID and user's authorization level before proceeding with its main task, as shown in the following illustration:

The Online Bank sample application includes a login AppLogic, OBLogin, which checks the user's password, looks the user up in a database, creates a user session and stores information about the user in it, then displays the appropriate menu depending on the type of user.

Designing Local, Distributed, and Global AppLogic Objects

When your application is ready for production use, the system administrator who deploys your application can specify the extent to which each AppLogic object is distributed by assigning one of the following types to the AppLogic:

• A local AppLogic is an AppLogic instance that runs on a particular iPlanet Application Server machine and does not participate in load balancing.

• A distributed AppLogic can run on any iPlanet Application Server machines that you and the system administrator specify, such as the machines in a cluster at a single company office. Each iPlanet Application Server might store a copy of the same AppLogic code, and the choice of which server runs the AppLogic at any particular time is made by the load balancing module of iPlanet Application Server.

• A global AppLogic can run on any iPlanet Application Server machine in the system, as determined by the load balancing module.

When designing an application, consider which AppLogics should be assigned to each category. These categories do not affect how you write the AppLogic code, but you need to communicate with the system administrator about which categories to use when the application is deployed.