Web Development

Chapter 1 . Overview of Panther Web Applications

Panther lets you easily build fully transactional, database-oriented applications to deploy on the Internet or an intranet. To understand how Panther works, this chapter presents:

How the Internet Works

The Internet is a global collection of computer networks. Because each computer on this network is able to communicate with any other, any resource that is on one is available to all. A resource can be a document, a picture, a sound file, a video clip—any information that can be stored and presented electronically.

Computers on this global network can communicate for these reasons:

The Internet's popularity vastly increased with the advent of the World Wide Web, originally designed for scientists to share information online. This information is deployed as hypertext documents that can contain hyperlinks (pointers) to other documents on the system.

The World Wide Web system uses these conventions:

Using a client/server model, information is stored on any of the computer servers that make up the web. That information can be accessed by a variety of clients or browsers—from an ASCII terminal to a PC running a graphical web browser.

In order to access documents on the web, a user starts a browser program. Every browser program can perform these tasks:

Retrieving Documents with URLs

Each document on the web has a unique URL, which allows other browsers to retrieve it. A URL contains these components:

The following example of a URL specifies that http is the protocol, the domain name is docs.prolifics.com, and the document named overview.htm is located in the docs/panther/html/web_html subdirectory of the HTTP server's document directory:



HTTP (HyperText Transfer Protocol) was developed specifically for transferring hypertext documents. Computer servers on the Internet, because they have programs installed to process HTTP requests, are called HTTP servers.

An HTTP server can also take data sent from the client and pass it on to programs on the server for further processing. These server programs are called gateway programs because they act as a bridge between the HTTP server and other local resources, such as databases. The interaction between the HTTP server and these programs is part of the CGI (Common Gateway Interface) specification.

Formatting Documents With HTML

HTML (HyperText Markup Language) is used to construct web documents. Each HTML document contains a series of tags. These tags identify each element of information in the document.

The web supports different types of clients, or browsers, to access the same information. HTML tags indicate the logical structure of a document; the actual implementation of these tags depends on the given browser, which has its own way to display the various parts of the document structure. So, presentation of HTML document data can differ in each browser. For example, on an ASCII terminal a heading might be centered on the terminal and appear all in uppercase characters. The same heading on a graphical web browser might start on the left side of the page and appear in mixed case, bold characters.

Each HTML tag is enclosed in a set of angle brackets (< >). The first instance of the tag is called the start tag. The second instance, in which a slash precedes the tag (</ >), is called the end tag. For example, the start tag for the body of a document appears as <BODY>. At the end of a document, the end tag appears as </BODY>. For some tags, the matching end tag is optional and is often omitted.

Viewing HTML in Web Browsers

Different browser programs can have different physical capabilities–for example, support for tables and graphic formats can vary. Furthermore, the browser program itself might permit the user to customize presentation of HTML elements; so two users who are using the same web browser program might see the same HTML document appear differently.

Browser presentation is especially susceptible to the base font that is specified for the browser program. A number of Panther widgets are resized according to the base font–text fields, static labels, dynamic labels, and labels on push buttons, radio buttons, and check boxes. Because text fields are also specified in HTML with a size property based on the number of characters, the resulting field changes in length according to the font size specifications in the browser.

Using the Internet and Intranets

If you have an Internet connection, you start your browser program and enter a URL. The browser then displays the resource specified in the URL. At that time, you can enter another URL; or, more typically, click on a hyperlink. A hyperlink's definition includes the URL of another web resource, which can be located anywhere on the Internet. When you click on a hyperlink, it opens that resource in your browser.

A web can be viewed as a collection of hyperlinked documents that exist either on the Internet or an intranet. Intranets and the Internet are different only in the scope of the network: an intranet only provides resources for a single company or organization.

The web is designed for easy access from one resource to another; it is not designed to retain information from previous resources–that is, it is stateless. Neither client nor server stores information about the other. After the server returns a resource to the browser, the connection between them ends. Each new request requires a new connection. The restrictions inherent in this stateless environment present a significant challenge to deploying transactional database applications on the web.

With Panther, however, you can build web applications that meet complex businesses requirements quickly and easily.

Panther has built-in components to store the state information needed for your application.

Components of a Panther Web Application

For a Panther web application, like any Panther application, you first develop your application screens and service components in the Panther editor. With its repository, screen wizard, and graphical, drag and drop environment, you have the tools to build your application quickly.

After the application's libraries are constructed, you can deploy the application on the Panther web application server, which works with your HTTP server software. Popular HTTP servers include Microsoft's Internet Information Server and Apache. The screens in your application can be requested from the HTTP server by entering the URL for the screen in a web browser.

When a browser request comes in for a Panther screen, the HTTP server passes the requested screen name to the Panther web application server. This is called a GET in the HTTP protocol. The web application server opens the screen, generates HTML for the screen, and passes the HTML back to your HTTP server, which transmits the data back to the browser that requested it.

In an HTML document, the Panther screen is translated into an HTML form. Embedded in this form is the screen's URL. After the user interacts with the screen and presses one of its push buttons, the screen is submitted back to the HTTP server. In the HTTP protocol, this is called a POST. The embedded URL tells Panther which screen to reopen. At that time, data from the HTML form is mapped into the Panther screen, and any processing attached to the activated push button is performed.

When these steps are complete, Panther generates HTML for the current screen and sends that data to the HTTP server, restarting the cycle. This cycle of browser requests occurs for all Panther web applications. However, the role of the web application server varies for two-tier and three-tier applications.

Two-Tier Processing

In traditional two-tier client/server processing, the web application server is responsible for making the database connections, opening the screens, mapping the browser and data cache values onto the screens, fetching data from the database, and generating HTML.

Figure 1-1 When the HTTP server receives a request from a browser for a Panther screen, the request is sent to Panther for processing.

Three-Tier Processing

In three-tier distributed processing, the Panther application server establishes and maintains connections to the database. When the web application requires data, the web application server, acting in the role of client, sends the service request to the Panther application server. The Panther application server processes this request and returns the desired data to the web application server.

In a three-tier environment, the web application server remains responsible for opening screens, mapping browser and data cache values, generating HTML.

Figure 1-2 In three-tier processing, the web application server is a Panther client.

Web Application Server Processes

When a web browser requests a Panther screen, the HTTP server passes the screen name to the web application server via the CGI, ISAPI, or NSAPI interface. The web application server opens the screen, generates HTML, and passes the HTML back to the HTTP server, which transmits the data back to the browser.

A web application server consists of three processes: requester, dispatcher, and jserver. By dividing its work among these separate processes, a web application server optimizes response time to each request and provides efficient service and options for high-volume applications.

Accepts a request from the HTTP server, passes it to a jserver process, and then waits for and transmits a response. There are three versions of the requester program, one for each type of interface: CGI, ISAPI, and NSAPI.

After receiving the request, performs all application-specific processing and, in three-tier applications, for routing service requests to the Panther application server. Unlike the requester, which shuts down after servicing a request, the jserver is always running. This allows Panther to provide prompt service to concurrent requests.

Manages the pool of jservers.

Figure 1-3 represents the interaction between the web application server processes:

Figure 1-3 The user request (URL) to the HTTP server initiates the startup of the web application server processes.

Panther's web application server architecture efficiently allocates server processes on a per-server basis, not a per-user basis, and reuses them for each request. This feature significantly reduces the load on your server.