Chapter 1   Introduction to Applications


This chapter provides an overview of iPlanet Application Server applications.

The following topics are included in this chapter:

• About iPlanet Application Server Applications

• Introduction to the iPlanet Application Server Foundation Class Library

• Introduction to Interfaces and COM

About iPlanet Application Server Applications

---

The cross-platform and universal access nature of the Internet and Intranet is enabling corporations to deliver online services to large numbers of users with ease and speed. Some examples of business services include travel, banking, online shopping, and stock trading services. iPlanet Application Server makes it possible for corporations to build, deploy, and manage applications that drive these on-demand, transaction-based services.

A key distinguishing feature between traditional client/server applications and iPlanet Application Server applications is the two-tier versus multi-tier model. In the two-tier client/server model, complex business and presentation code reside on the client. The client code needs to be configured and maintained on individual clients that often run different operating systems.

In the multi-tier model, iPlanet Application Server is the middle tier. Business code is stored and processed on iPlanet Application Server rather than on clients. An application is deployed and managed in a single location, and is accessible to large numbers of heterogeneous clients.

The iPlanet Application Server software is shipped with several sample applications which you can look at to get a more detailed overview. For example, the Online Bank sample application provides online banking and customer management. Customers using Web browsers can log in to Online Bank over the Internet, view account information, and move funds between accounts. Bank employees can use Online Bank to display information about customers, add new customers, and update or delete existing customer data.

Applications as Part of a Three-Tiered Environment

iPlanet Application Server applications run in a distributed, three-tiered environment. This means that an iPlanet Application Server system might consist of several computers running multiple copies of iPlanet Application Server software, along with multiple database servers and Web servers. Your application code can be distributed among the iPlanet Application Servers and on client machines. Overall, the machines and software involved are divided into three layers, or tiers.

The following illustration shows iPlanet Application Server application code in the three-tiered environment:

Client Tier Code

The first tier is the client, or user interface, tier. End users interact with client software in order to use the application. The software providing the user interface can be either a Web browser displaying HTML pages or a client application installed on desktop PCs.

Middle Tier Code

The middle tier is iPlanet Application Server itself. This tier consists of server machines running both iPlanet Application Server software and your server-side application code. You write this portion of the application code using the iPlanet Application Server Foundation Class Library.

The iPlanet Application Server handles requests from clients by running the appropriate application code, then returns the results to the clients. The means of communication between the client tier and iPlanet Application Server is the Internet or an Intranet. In the case of HTML clients, a Web server also stands between the client and iPlanet Application Server. The Web server passes requests and responses back and forth between HTML clients and iPlanet Application Server.

Database Tier Code

The third tier is the database tier. This tier consists of one or more database servers, which can be from different vendors. The database tier stores the information that forms the basis of the application. For example, in the Online Bank sample application, a database is used to keep track of customer information, account information, and transactions.

The code in the database tier can be created in a variety of database applications, and is therefore outside the scope of this documentation. You will need to write code in the server tier, using the iPlanet Application Server Foundation Class Library, to interact with the database tier. For more information, see Working with Databases.

Example Three-Tiered Application

As mentioned earlier, the Online Bank sample application, which is shipped with iPlanet Application Server, provides online banking and customer management. Online Bank is a good example of a three-tiered iPlanet Application Server application. The following discussion describes a typical user session with this application.

The User Logs In
If the client tier strategy used in Online Bank consists of HTML pages displayed in Web browsers, a bank customer can log in to the application from home, or wherever they have access to the Web. To begin working with the application, the user opens a Web browser and requests URL of the first HTML page in the application, the login page.

The Server Responds By Accessing The Database
After typing a user ID and password, the user clicks the Login button. This causes an action request to be sent to iPlanet Application Server (if the clients are Web browsers, the request is first sent to the Web server, which forwards it to iPlanet Application Server). The iPlanet Application Server handles requests by running the appropriate application code.

In this case, the code needed is that which logs in the user. In order to validate the user's password, the application accesses the database tier, where information about users is stored.

The Server Returns Results
After looking up the user's ID and password in the database, the application can validate the user and send a response back to the client tier. In a Web browser application, the server sends an HTML page containing the main menu of the application back to the user's Web browser (assuming the user was validated successfully).

The User Continues Using the Application
The user might next ask for the current balance in their checking account, which the iPlanet Application Server handles by querying the database, formatting the data into a report, and sending the report back to the user. 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.

Introduction to the iPlanet Application Server Foundation Class Library

---

A library is a set of predefined interfaces and class declarations that can be used in object-oriented programs. The iPlanet Application Server Foundation Class Library is designed for building server-side code as part of iPlanet Application Server applications. The class library is stored in the iPlanet Application Server installation directory, and is copied to your disk when you install iPlanet Application Server.

The classes and interfaces in the iPlanet Application Server Foundation Class Library define many types of objects you can include in iPlanet 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 iPlanet Application Server Foundation Class Library:

• AppLogic objects

• Data connections

• Queries and other database commands

• Dynamic reports

• Electronic mailboxes

• User sessions and session-related data

• Security

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

Introduction to Interfaces and COM

---

The iPlanet Application Server programming API is based on interfaces and the Component Object Model (COM). 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 COM?

The Component Object Model (COM) is a specification that provides a standard way for objects and their clients to interact. COM specifies only how objects interact, not how applications are structured internally or how they are implemented.

The fundamental mechanism which COM defines for this purpose is called an interface. An interface is a description of the services provided by an object. Clients wishing to use a COM object need only know what interface the object supports.

For more information about interfaces, see What Is an Interface?.

Benefits of COM

The purpose of COM is to promote software interoperability. Applications are made up of objects that can easily cooperate with one another, even when the objects are:

• Written in different programming languages

• Running on different machines under different operating systems

• Used by different client applications.

Unlike other object-oriented programming techniques, the COM standard does not depend on what type of client is attempting to use a particular software object, nor does it depend on which programming language is used to implement the object. COM provides a standard framework through which all software objects can interact.

COM provides a more productive way to design, implement, distribute, and reuse software. By reusing components, developers are free to spend more time on the functionality that is specific to their business situation.

How to Use COM

You use the Component Object Model to create reusable software components. These components must adhere to the COM standard and use interfaces to define their expected behavior to clients, but you can implement the internal behavior of components in any way you wish.

At the minimum, every COM object provides two basic operations:

• Find out which interfaces an object supports by calling the QueryInterface( ) method. For more information, see Getting Information About Interfaces.

• Control the object's lifetime by calling the reference counting methods AddRef( ) and Release( ). For more information, see Reference Counting.

All three of these methods are defined in the IUnknown interface, which is the base interface from which all COM interfaces inherit.

What Is an Interface?

The objects in iPlanet 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 wishes to interact with it). The contract describes a set of expected behavior. Code that wishes to use an object need only know what interface the object supports, and does not need to know anything about the internal implementation of the object.

An interface defines a set of functions, called methods. The interface includes no implementation code. It only describes 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, such as IGXQuery.

Benefits of Using Interfaces

Interfaces provide a level of abstraction that enables objects to interoperate more easily. The code which wants to 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 wishes to connect. The interface provides the connection that allows the code to access the object, and allows the object to expose its services.

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