Previous Next Contents Index


Overview of NAS Applications

This chapter introduces Netscape Application Server and key concepts for developing, deploying, and managing web applications.

The following topics are included in this chapter:


About Netscape Application Server
Netscape Application Server is the middleware between enterprise data sources and the clients that access these data sources. Business code is stored and processed on Netscape Application Server (NAS) rather than on clients. An application is deployed and managed in a single location, and the application is accessible to large numbers of heterogeneous clients.

NAS applications run in a distributed, multitiered environment. This means that an enterprise system might consist of several application servers (computers running the Netscape Application Server software), along with multiple database servers and web servers. Your application code can be distributed among the application servers.

Overall, the machines and software involved are divided into a client tier, a server tier, and a data tier, as shown in the following figure:

Client Tier The client tier is the user interface. End users interact with client software to use the application. For the current release of NAS, the client software is assumed to be a web browser (such as Netscape Navigator). In future releases, NAS will also support end-user access through rich clients running RMI over IIOP for requests originating from CORBA clients.

Server Tier The server tier consists of at least one web server and at least one application server. Netscape Application Server handles requests from clients by running the appropriate application code, then returns the results to the clients over the Internet or over an intranet. For web clients, a web server stands between the clients and the application server, passing HTTP requests and responses back and forth among the servers and clients.

The application server runs the NAS software as well as your server-side application code. You write this portion of the application code using standard Java APIs and, optionally, NAS feature APIs.

The standard Java APIs include the following:

Sun Microsystems drives both the development of these APIs and the publication of the API specifications. These processes include participation from key vendors of Java technology and from the general public. As a result, these APIs are emerging as an industry standard. All specifications are accessible from installdir/nas/docs/index.htm, where installdir is the location in which you installed NAS.

In addition to using the standard APIs, you can also develop custom NAS features or provide backward-compatibility to existing NAS applications. To do so, use the Netscape Application Server Foundation Class Library. For more information about this library, see the Netscape Application Server Foundation Class Reference.

Data Tier The data tier consists of one or more enterprise data sources, such as

The data tier stores the data that forms the basis of an application. For example, a relational database may be used to keep track of customer information, account information, and inventory. Code in the data tier can be created using a variety of database applications, SQL tools, or other third-party applications. Describing how to write this code is outside the scope of this guide.

As a developer of NAS applications, you must create the business logic that accesses the data tier. To do so, you typically use the Java Database Connectivity (JDBC) API.


Sample Three-Tiered Applications
The Online Bank sample application, which is shipped with Netscape Application Server, provides online banking and customer management. Online Bank is a good example of a three-tiered Netscape Application Server application. The following steps describe a typical user session with this application.

  1. The user logs in.

  2. The server responds.

  3. The server returns results.

  4. The user continues using the application.
This cycle of request, query, and response is repeated many times as the customer makes other selections and navigates through the application. Requests come in from the client tier and are processed in the server tier, often by accessing the database tier. Responses are then sent back from the server to the client.

Note. An additional sample three-tiered application based on an online bookstore is described in detail in Inside the Online Bookstore Sample Application


The Application Model
An application model is the conceptual division of a software application into functional components. The application model for Netscape Application Server is shown in the following figure:

The application model consists of three layers:

Each layer is further described in separate sections of this chapter.

The application model is based on Java standards. By implementing these widely adopted standards, the NAS application model makes development more component oriented and promotes code reuse.

The following table lists the standards-based application components associated with each area of the application model:

Functional area
Application component
Presentation logic and layout
Java servlets for logic;
JavaServer Pages (JSPs) for layout.
Business logic
Enterprise JavaBeans
Data and legacy access
Enterprise JavaBeans that use either JDBC interfaces, distributed transactions, or both.

A Java servlet is an application component—a Java object that is an instance of the Servlet class. The Servlet class is among the code defined in the Servlet API specification.

A JavaServer Page (JSP) is an application component used for presenting dynamically generated content. JSPs are text files written in a combination of standard HTML tags, JSP tags, and Java code.

Enterprise JavaBeans is a component model for developing and deploying Java applications in a multitiered, distributed architecture. The components themselves are referred to as Enterprise JavaBeans (EJBs).

The JDBC API is a standards-based set of classes and interfaces that enable developers to create data-aware EJBs.

Design-Time Advantages By dividing an application into functional areas, developers more clearly understand how to design and build an application and what tools to use. In addition, the development cycle is more efficient because each type of developer—web master, database expert, Java programmer, user interface designer, and so on—can focus on distinct areas of the application.

Furthermore, dividing presentation functionality into a separate layer makes the application more flexible. For example, when you want to change the presentation style of an e-commerce application, you can do so without changing the logic in the business layer or data access layer.

Deployment-Time Advantages The division of an application is conceptual. It occurs in the design of the application, not necessarily in its deployment. However, the way you design an application can make different deployment options possible.

For example, you can deploy an application to run on one computer, or you can scale the application to run on a cluster of servers. Each server can be dedicated to a separate application task, or the servers can work redundantly to allow for load balancing or failover recovery.

In summary, the application model makes it possible to deploy a fully distributed, network-oriented application.

Functional View of the Application Model The following figure shows typical interactions between these layers.


The Presentation Layer
The presentation layer offers a user interface to the application's end user. This layer determines the application's "look and feel".

In the NAS application model, presentation is controlled by the presentation layer. This layer separates business logic from presentation on the client.

The presentation layer consists of two main functional areas:

Presentation logic handles such tasks as page-to-page navigation, session management, simple input validation, and the tying together of business logic.

Presentation layout involves issues typical to web page design, such as creating HTML and images that load efficiently, adhering to corporate design standards, and deciding what buttons or menus will be available on particular pages.

In addition to supporting the standard Java servlets and JavaServer Pages, the presentation layer supports validation of incoming requests, as well as interaction with other application components (for instance, Enterprise JavaBeans).

About Servlets Java servlets provide an application's presentation logic. A servlet is an application component that runs inside a server. A servlet is an instance of the Servlet class. Servlets are similar to applets, which are client-side Java components.

Java servlets handle such tasks as request processing, session management, and the tying together of business logic. Servlets can make calls to JSPs, Enterprise JavaBeans, and JDBC RowSet objects.

About JavaServer Pages JavaServer Pages (JSPs) are used for output processing. A JSP is an HTML file containing a mix of HTML, special JSP tags, and Java code. JSPs act as output templates, separating the presentation of dynamic content from the generation of that content. As a result, developers can code most output to be delivered by HTML files instead of having to issue cumbersome print statements with HTML code in them.

Application Processing NAS applications consist of a set of Java classes that define the servlets, and a set of JSP files that define output responses. There is an API for expanding templates from a servlet. An application in NAS 4.0 also needs several configuration files for initializing the servlet engine with information about the application.

The application model is based on the following:


The Business Logic Layer
The business logic layer maintains the application-specific processing and business rules of an application. The application components in the business logic layer connect those in the presentation and data layers. These components define an application's processing logic, processing flow, and connections to back-end data sources.

About EJB Functionality In the NAS application model, the business layer is implemented using Enterprise JavaBeans. Enterprise JavaBeans support the following functionality:

About Session Beans and Entity Beans There are two types of Enterprise JavaBeans: session beans and entity beans.

Session beans relate to units of work, such as a request for data. Session beans are short lived—the lifespan of the client request is the same as the lifespan of the session bean. Session beans can be stateless or stateful, and they can be transaction aware.

Entity beans relate to physical data, such as a row in a database. Entity beans are long-lived, because they are tied to persistent data. Entity beans are always transactional and multiuser aware.


The Data Access Layer
The data access layer provides Enterprise JavaBeans with access to back-end data sources. In the NAS application model, Enterprise JavaBeans access relational databases using JDBC APIs.

To access other data sources, your code may need to make a call into an extension. Netscape Application Server includes prebuilt extensions. These extensions allow an application to communicate with transaction-processing systems such as CICS/IMS, IBM MQSeries, and BEA Tuxedo. Additional prebuilt extensions allow communication with Enterprise Resource Planning (ERP) systems such as SAP R/3. If you need to create a custom extension, use Netscape Extension Builder.

As part of the EJB standard, NAS supports distributed transactions. This support means that NAS applications can ensure data integrity because the server manages transactions across multiple back-end databases.


How You Create Application Components
To create application components, you can use basic tools. For example, you can use a text editor to create Java source code or JSPs. More likely, you will want to use a visual editor or an integrated development environment (IDE) such as Netscape Application Builder.

As you develop NAS applications, you create Java files that use a number of APIs:

These APIs are listed in Appendix A, "Summary of Standard APIs." Because Sun owns the process of publishing these APIs, the appendix also includes web links to more information.

Along with the standard APIs, applications can use the API that ships with NAS. This API provides:

The NAS API is more formally known as the Netscape Application Server Foundation Class Library and is summarized in the following sections.

About Class Libraries A library is a set of predefined interfaces and class declarations that can be used in object-oriented programs. The Netscape Application Server Foundation Class Library contains interfaces and classes for developing server-side code.

The Netscape Application Server Foundation Class Library is designed for building server-side code as part of NAS applications. The class library is stored in several packages in the Netscape Application Server installation directory and is copied to your disk when you install Netscape Application Server.

The classes and interfaces in the Netscape Application Server Foundation Class Library define many types of objects you can include in Netscape Application Server applications. Each object provides a specific type of functionality that is commonly needed. The following list shows some of the major types of objects and functionality you can include in your application by using the Netscape Application Server Foundation Class Library:

This is just a partial list. For complete information about the Netscape Application Server Foundation Class Library, see the Netscape Application Server Foundation Class Reference.

About Interfaces The Netscape Application Server programming API is based on interfaces. This section provides an overview of the concepts involved in such a programming model. You do not need to read this section if you are already familiar with these concepts.

What Is an Interface?
The objects in Netscape Application Server applications interact through interfaces. An interface is a description of the services provided by an object. An interface is like a contract between an object and its user (the code that wants to interact with it). The contract describes a set of expected behavior. Code that wants to use an object need only know what interface the object supports; code does not need to know anything about the internal implementation of the object.

An interface defines a set of functions, called methods. The interface has no implementation code. It describes only the parameters and return types of its methods. The code for the methods is written separately, in a class, which is said to implement the interface. Typically, the interfaces and their implementations are written by different groups of people.

How is an interface different from a class? A class is a set of data and functions (member variables and methods) that define the characteristics of one type of object. An object is an instantiation of a class. An interface, like a class, defines the characteristics of a particular type of object. However, unlike a class, an interface is always abstract. A class can be instantiated to form an object, but an interface can not be instantiated, because it has no implementation code to determine what to do when each method is called.

Every interface has a name that serves as an identifier you can refer to in code. By convention, the name of each interface begins with a capital I, for instance, IBuffer.

Benefits of Using Interfaces
Interfaces provide a level of abstraction that enables objects to interoperate more easily. The code that will use the object needs to know how to connect to the object and call its methods. The object needs to expose its services to any code that wants to connect. The interface provides the connection that not only allows the code to access the object, but also allows the object to expose its services.

When using an interface-based programming model, you can modify the internal implementation of an object whenever you need to. As long as the object continues to implement the same interface, the code that uses that object does not require rewriting or recompilation.

 

© Copyright 1999 Netscape Communications Corp.