Previous Next Contents Index


Designing NAS Applications

This chapter summarizes the process of designing NAS applications and offers guidelines for effective design.

Designing applications for NAS involves four main steps, described in the following sections:


Identifying Application Requirements
In any development cycle, the first step—and arguably the most important step—is to gather the requirements of the application. This step may take weeks or months, and it involves your product management or product marketing team.

As a brief example, suppose you are developing an online banking application. After discussions with your customers, you might come up with the following requirements. This list is a just a sample, and does not include actual numbers.

Defining the Requirements Along with identifying requirements, you may need to further define them. Understanding the requirements in detail helps establish the business rules and design guidelines. For example, you might look more closely at who the end users are.

Will users be anonymous, or will they be required to login? In many cases, an application provides introductory web pages that are freely browsable by anonymous users, while other pages would require logging in as a registered users. Registered users might be further classified as regular or premier customers, depending on specified criteria. What are these criteria? For example, a customer may earn premier status by purchasing at least $500 worth of merchandise per month or by maintaining a minimum of $5000 in an account.

Matching Requirements to the Application Model Designing toward your requirements may affect one or more layers in the application model. Consider the end-user requirements, for example.

In the presentation layer, the application may need to present one set of pages for anonymous users, and another set for registered users. Also, when an anonymous user tries to access a feature reserved for registered users, you might design the application to present a page that explains why the attempt 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 category of end user.


Assembling the Development Team
The application model allows different individuals to focus on developing application elements at the same time. This section describes the skills needed from designers and developers for each application layer. The following categories are described:

The composition of the team depends on the size of your group and the scope of the application. For example, not all team roles may be needed, and team members could assume more than one area of responsibility.

The Architect In component-based application development, one or more individuals must have an overall vision of the application, its control flow, and other interactions. Some organizations call this person the architect. Regardless of the name you use, this individual serves an important role by coordinating the efforts of the various design teams and by helping them think about "the big picture."

Team Roles for the Presentation Layer The presentation layer is where the user interface is dynamically generated. The following team members are needed:

Servlet developers create the presentation logic, whereas the other roles are for creating the presentation layout.

Java Servlet Developers
Servlets handle page-to-page navigation, session management, and simple input validation. Servlets also tie business logic elements together.

A servlet developer must understand issues related to HTTP requests, security, internationalization, and web statelessness (such as sessions, cookies, and timeouts). For NAS applications, servlets must be written in Java. Servlets are likely to call JSPs, EJBs, and JDBC RowSet objects. Therefore, a servlet developer works closely with the developers of those application elements.

JSP Developers
JSP developers work closely with servlet developers to define the application's presentation screens and storyboards (page navigation). Even on complex development projects, the same person may develop both JSPs and servlets. However, if you design the application so that most of the Java is in servlets rather than in JSPs, a JSP developer need not be proficient in Java.

JSPs are likely to call EJBs and JDBC RowSet objects.

HTML Designers
HTML designers optimize HTML pages. For example, designers might perform any of the following tasks:

Graphic Artists
Graphic artists create images that end up as GIFs or JPEGs. These images must be appropriate to the application and must be quick to download. Graphic artists work closely with HTML designers.

Client-Side JavaScript Developers
Client-side JavaScript can be used for several reasons. For example, it can handle simple input validation before passing data to the server, or it can make the user interface more exciting. Client-side JavaScript developers work closely with developers of servlets and JSPs.

Team Roles for the Business Logic Layer The business logic layer encapsulates business rules and business entities. The following team members are needed:

Session Bean Developers
Session beans encapsulate the logic for business processes and business rules. For example, a session bean might be developed to calculate taxes for a billing invoice. Applications usually handle complex business rules that can change frequently (for example, due to new business practices or new government regulations). As a result, an application typically uses more session beans than entity beans, and session beans may need continual revision.

A developer of session beans typically is a domain expert and understands complex, domain-specific logic as well as data validation rules. This developer works closely with developers of servlets and entity beans.

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 tax is calculated in a stateful session bean. The application must then access a particular server where that bean's state information resides. If the server happens to be down, then application processing is delayed.

Entity Bean Developers
Entity beans represent persistent objects, such as a row in a database. The role of an entity bean developer 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.

As a result, an entity bean developer typically understands issues such as caching, coherency, indexing, database performance and transactions, and object-relational mapping. An entity bean developer is similar to the schema developer in a relational database environment.

Entity beans are less likely than session beans to require changes, because the organization of enterprise data is usually a mature process, so database schema tend to be stable. Besides, frequent changes to an organization's data model incur a high cost for redevelopment and retesting.

An entity bean developer works with developers of session beans and servlets to ensure that the application provides fast, scalable access to persistent business data.

Entity beans are likely to call a full range of JDBC interfaces. However, entity beans typically do not call other EJBs.

Team Roles for the Data and Legacy Access Layer In the Data and Legacy Access layer, the main role is the developer of custom extensions. These developers are very likely to use C++, and they typically need to understand issues related to wrapping C++ in Java, such as Java Native Interfaces (JNI).

Extension developers use Netscape Extension Builder. They are likely to integrate access to the following systems:

After the development team is assembled, the application's user interface can be designed.


Designing the User Interface
It is recommended that you design your application from front to back. That is, you should design the user interface before you design or develop EJBs. In this way, you ensure the most efficient application flow.

Begin by planning the navigation storyboards and UI screens. There are many third-party books and online guides that teach web site design. The following list summarizes the questions you may need to resolve:

The specific tasks related to creating servlets and JSPs are covered in Part II of this guide.


Guidelines for Effective Development
This section lists some of the guidelines to consider when designing and developing a NAS application. This section is merely a summary. For more details, refer to later chapters in this guide.

The guidelines are grouped into the following goals:

Easing Development Maintaining or Reusing Code Improving Performance Planning for Scalability

 

© Copyright 1999 Netscape Communications Corp.