1

Understanding Developer/2000 for the Web

This chapter covers these topics:

■ Introduction to Developer/2000 for the Web
■ Benefits of Developer/2000 for the Web
■ Forms Web Architecture
■ Reports Web Architecture
■ Graphics Web Architecture

1.1 Introduction to Developer/2000 for the Web

Developer/2000 for the Web is a new generation of Oracle development tools that
enable you to deploy new and existing applications on the World Wide Web, either
on an internal company intranet, or on the Internet. Developer/2000 for the Web
takes advantage of the ease and accessibility of the Web, and elevates it from a
static information-publishing mechanism to an environment capable of supporting
complex, dynamic applications.

1.1.1 The best of the Web and client-server

Developer/2000 for the Web provides solutions that enable you to leverage the
benefits of the Web, while maintaining the strengths of client-server computing.
The Web greatly reduces the costs of administering and maintaining applications,
while allowing for a thin, low-cost client. At the same time, it allows you to
leverage your existing client-server applications, which may be mission-critical
applications that support—and often drive—your business practices. These
applications must be scalable to large numbers of users and open to all of your
environments.

Understanding Developer/2000 for the Web 1-1

1.1 Introduction to Developer/2000 for the Web

1.1.2 Three-tiered architecture

In most client-server implementations today, running applications is a highly client-
intensive process. Though data is extracted from a remote database server,
applications run on client machines, which often have limited processing power
and memory capacity.
Developer/2000 for the Web supports a three-tiered architecture that delivers the
benefits of both client-server and the Web in a single application. In a Web
implementation, application logic and processing are focused on a middle tier of
application servers instead of on desktop client machines.

Tier Hardware
front-end any number of client desktop machines
middle one or more application servers
back-end one or more database servers

Figure 1–1 Three-tiered architecture

1-2 Understanding Developer/2000 for the Web

 1.2 Benefits of Developer/2000 for the Web

1.2 Benefits of Developer/2000 for the Web

Developer/2000 for the Web benefits groups across the spectrum of the application
life-cycle, including managers, developers, and end users. Each group benefits by
gains in productivity, reduced resource requirements, and lower costs:
■ Low-cost deployment and maintenance Web applications are deployed and
maintained on centralized application servers, from which they download to
end users’ Web browsers at runtime. To roll out a Web application, simply give
end users the application’s URL. This distribution method reduces the time,
cost, and complexity of deploying applications to a large or geographically-
dispersed end-user base, all without installing application software on their
desktop machines.
■ Client-server migration Developer/2000 for the Web extends and leverages the
traditional strength of Oracle’s client-server development suite.
Developer/2000 for the Web supports all GUI widgets available in a client-
server application, so you can Web-deploy any existing client-server
application without changing the form definition (.FMB file)1. You can run the
same Forms executable (generated .FMX file) in client-server mode or on the
Web. Programmers experienced with Developer/2000 do not need to learn Java,
JavaScript, or any other new language.
■ “Thin Client” architecture Any end user with a Java-enabled2 Web browser can
run Web applications. This single client-side requirement greatly reduces
processor and memory requirements for a user’s desktop machine.
■ Support for various business objectives With Developer/2000 for the Web, you can
develop internal, transaction-intensive applications (deployed on a company
intranet), and electronic commerce applications (deployed on the Internet).
End users accustomed to client-server applications will enjoy similar
performance with Developer/2000 for the Web.
■ NC support Developer/2000 for the Web is designed in accordance with
Oracle’s Network Computing Architecture (NCA). Developer/2000 applications
run as NCA-compliant Web cartridges.

1
See Section 3.2.8, “Feature restrictions for Forms on the Web.”
2
Java 1.1.1 or higher

Understanding Developer/2000 for the Web 1-3

1.2 Benefits of Developer/2000 for the Web

■ Platform independence Developer/2000 for the Web leverages Java—the emerg-

ing standard platform-independent language—to map GUI widgets to their
native counterparts on other platforms. The look and feel of widgets will differ
only slightly between end user platforms (Windows, Mac, Motif, and so on).
■ Dynamic reporting and Web authoring With no additional training, you can use
the declarative, point-and-click interface of Developer/2000 Reports to create
Web reports. To Web-enable existing reports, simply regenerate them in HTML
or PDF. Use the CGI interface to set up reports to run dynamically from a Web
browser, and to author Web pages on the fly.
■ Drill-down reports Developer/2000’s Web-publishing capabilities include
reporting features that enable end users to navigate through layers of a
particular report. You can associate a URL with a field in a report; end users
then can click the field to navigate to another Web page. The new page
displays detailed report data corresponding to the clicked field.

1-4 Understanding Developer/2000 for the Web

 1.3 Forms Web Architecture

1.3 Forms Web Architecture

To run new or existing Forms applications on the Web, you should install and
operate Developer/2000 for the Web on the middle tier of a distributed three-tiered
architecture (see Figure 1–1).

1.3.1 About the Forms Client and Forms Server

The Forms component of Developer/2000 for the Web consists of two components:
the Forms Client and the Forms Server.

1.3.1.1 Forms Client

The Forms Client is a Java applet—downloaded at runtime from an application
server to an end user ’s Web browser—that displays the form’s user interface and
manages interaction between end users and the Forms Server. The Forms Client
receives “bundles” of interface commands from the Forms Server and translates
them (in sets) into interface objects for the end user. Some interface events handled
by the Forms Runtime Engine in a client-server implementation (such as typing
characters in a text field, or moving around a dialog) occur only on the Forms
Client in the Web implementation, with no interaction with the Forms Server
Runtime Engine.
The Forms Client is:
■ Generic You are not required to deploy a separate Java applet for each
application you wish to deploy on the Web.
■ Dynamic The Forms Client dynamically reacts to the current form at runtime,
requesting and displaying only the information and user interface elements
necessary to represent the current state of the application at any given time.
■ Feature-rich The Forms Client supports all user interface widgets and tools
available in a client-server implementation. Due to Java object standards, the
look and feel of some Forms widgets may vary slightly when deployed on the
Web. For more information, refer to Section 3.2.8, “Feature restrictions for
Forms on the Web.”
■ Thin At startup, only those class files necessary to render the initial state of an
application are downloaded to the end user’s machine. Additional class files
are downloaded dynamically (as needed) to support additional user interface
functionality.

Understanding Developer/2000 for the Web 1-5

1.3 Forms Web Architecture

1.3.1.2 Forms Server

The Forms Server consists of two components:
■ Listener The Forms Server Listener initiates the Forms runtime session and
establishes a connection between the Forms Client and the Forms Server
Runtime Engine.
■ Runtime Engine The Forms Server Runtime Engine is a modified version of the
Forms 4.5 Runtime Engine, with user interface functionality redirected to the
Forms Client. It handles all form functionality except UI interaction, including
trigger and commit processing, record management, and general database
interaction.

1-6 Understanding Developer/2000 for the Web

 1.3 Forms Web Architecture

1.3.1.3 Client-server architecture vs. Web architecture

There is a significant difference between deploying a Forms applications in client-
server mode and deploying the same application on the Web:
■ Client-server The Forms Runtime Engine (and all application logic) are installed
on end users’ desktop machines. Although your application can include
database-server-side triggers and logic, typically all user interface and trigger
processing occurs on client machines.

Figure 1–2 Forms: client-server architecture

Understanding Developer/2000 for the Web 1-7

1.3 Forms Web Architecture

■ Web The Forms Server Runtime Engine (and all application logic) are installed
on application servers, not on client machines. All trigger processing occurs on
database and application servers, while user interface processing occurs on the
Forms Client.

Figure 1–3 Forms: Web architecture

1-8 Understanding Developer/2000 for the Web

 1.3 Forms Web Architecture

1.3.1.4 Call and response: Forms Client and Forms Server

Once a direct network connection is established between the Forms Client and
Forms Server, the two components communicate through a series of requests and
responses—via compressed messages passed over a network.
Requests from the Forms Client are events (such as “click button” or “display
LOV”). Responses from the Forms Server are a series of changes to the user
interface (such as value changes, and adding and removing components), all of
which the Forms Client converts to display objects.
For example, the Forms Client might receive a response from the Forms Server
similar to “create four green text items on canvas CAN_12.” The Forms Client
translates the response into actual interface objects, in this case, the verdant text
items.
The Forms Client contacts the Forms Server when users perform:
■ high-level operations (such as accepting or canceling a dialog)
■ operations (such as checking a checkbox or navigating between fields) that
involve validation processing and cause default and user-defined triggers to fire

Understanding Developer/2000 for the Web 1-9

1.3 Forms Web Architecture

1.3.2 Running Forms applications on the Web

Figure 1–4 Running Forms applications on the Web: process flow

To start and run a Forms application on the Web, end users use a Java-enabled Web
browser to access a URL. The following sequence occurs automatically:
1. The URL corresponds either to a static (non-cartridge) HTML page, or to an
application cartridge, residing on the application server.
2. An HTML page, and then the Forms Client applet, are downloaded from the
application server to the user’s browser.
3. The Forms Client sends a request to the Forms Server Listener (which resides
on a specific port of the machine from which the Forms Client was
downloaded).
4. The Listener contacts the Forms Server Runtime Engine and connects to a
Forms runtime process (either by starting a new process, or by connecting to an
existing process). If included in the HTML page, Forms command-line
parameters (such as form name, user ID and password, database SID, menu

1-10 Understanding Developer/2000 for the Web

 1.3 Forms Web Architecture

name, and so on) and any user-defined Forms parameters are passed to the
process by the Listener.
5. The Listener establishes a direct socket connection with the Runtime Engine,
and sends the socket information to the Forms Client. The Forms Client then
establishes a direct socket connection with the Runtime Engine. The Forms
Client and Runtime Engine then communicate directly, freeing the Listener to
accept startup requests from other end users. The Forms Client displays the
application’s user interface in an applet window outside the main window of
the end user’s Web browser.
6. As in a client-server implementation, the Runtime Engine communicates
directly with the database through SQL*Net (or another driver, for non-Oracle
datasources).

1.3.3 Security and encryption

Data passed between the database, the Forms Server, and the Forms Client is
automatically encrypted before—and decrypted after—transmission by the
following protocols:
■ RSA RC4 40-bit encryption (for transmissions between the Forms Client and
the Forms Server)
■ SQL*Net SNS/ANO (for transmissions between the Forms Server and the
database server)
Encryption is enabled by default, but can be disabled. To disable encryption
between:
■ the Forms Client and Forms Server, set the environment variable
FORMS45_MESSAGE_ENCRYPTION to FALSE.
■ the Forms Server and the database, refer to the Oracle Advanced Networking
Option Administrator’s Guide.

Understanding Developer/2000 for the Web 1-11

1.4 Reports Web Architecture

1.4 Reports Web Architecture

With traditional two-tiered, client-server architecture, displaying a report on the
Web involves generating HTML or PDF output on the client, moving the file to a
location on the server, and linking it to a Web page where users can access it from a
Web browser. Automating the process with a third-party scheduling tool or
operating system facility makes this a reliable method of publishing and updating
reports on the Web.
There may be cases, however, when it is necessary to provide end users with the
most current data, on demand. With the multi-tier architecture of
Developer/2000 for the Web, end users can run reports dynamically on a remote
application server from any client.

1.4.1 Dynamic Reporting with the Web Cartridge or Common Gateway Interface (CGI)
To enable end users to generate reports dynamically from a Web browser,
Developer/2000 for the Web provides a Reports Server suite that includes the fol-
lowing components:
■ The Reports Multi-tier Server (R25MTS), which enables you to run reports on a
remote server.
■ The Reports Web Catridge (R25OWS), which sends requests from the Web
server to the Reports Multi-tier Server if you are using the Oracle Web Applica-
tion Server.
■ The Reports Web CGI (R25CGI), which sends requests from the Web server to
the Reports Multi-tier Server using standard CGI.

1.4.1.1 About the Components

1.4.1.1.1 About the Reports Multi-tier Server The Reports Multi-tier Server enables you
to run reports on a remote, application server. When used in conjunction with the
Reports Web Cartridge or Web CGI, it also enables you to run reports from a Web
browser using standard URL syntax. The server can be installed on Windows NT,
Windows 95, or Unix. It handles client requests to run reports by entering all
requests into a job queue. When one of the server's runtime engines becomes avail-
able, the next job in the queue is dispatched to run. As the number of jobs in the
queue increases, the server can start more runtime engines until it reaches the maxi-
mum limit specified when the server process was started. Similarly, idle engines
are shutdown after having been idle for longer than a specified period of time. You
can monitor and administer the job queue on Windows using the Reports Queue

1-12 Understanding Developer/2000 for the Web

 1.4 Reports Web Architecture

Manager (R25RQM32.EXE). On Unix, you can use the Reports Queue Viewer
(R25RQVM)

1.4.1.1.2 About the Reports Web Cartridge The Reports Web Cartridge is a library (on
Windows NT, a dynamically linked library or .dll file, on Sun Solaris, a shared
library or .so file). It performs the same functions as the Reports Web CGI, but it
has the advantage of native integration with the Oracle Web Application Server.
Once installed, it is always up and ready. The CGI executable has to be started up
every time it is invoked. The cartridge typically resides in the $ORACLE_HOME/
bin directory and is installed using the Web Request Broker of an active Oracle Web
Application Server Listener.

1.4.1.1.3 About the Reports Web CGI The Reports Web CGI provides a standard CGI
connection between a Web server and the Reports Multi-tier Server. This connec-
tion enables a Web client to run reports using standard URL syntax and see the out-
put on the client's Web browser. R25CGI is designed to run under WWW CGI v1.1.

1.4.2 Running Reports on the Web

Figure 1–5 Running Reports on the Web: process flow

To start a report on the Web, end users point to a URL from their Web browsers.
The following sequence then occurs:

Understanding Developer/2000 for the Web 1-13

1.4 Reports Web Architecture

1. The Web browser passes the URL to the Web server, and the Web server sends
the request to the Reports Web Catridge or CGI.
2. The Reports Web Catridge or CGI parses the request and converts it to a com-
mand line that can be executed by the Reports Multi-tier Server. Then it sub-
mits the command line to the specified Reports Multi-tier Server
(synchronously).
3. The Reports Multi-tier Server queues the job request from the Web Cartridge or
CGI and, when one of its runtime engines becomes available it runs the report.
4. The Reports Web Cartridge or CGI retrieves the name of the report output
from the server and creates HTTP redirection to the output file.
5. The Web server executes HTTP redirection, passing the new URL back to the
Web browser, and the report is displayed on the client.

1-14 Understanding Developer/2000 for the Web

 1.5 Graphics Web Architecture

1.5 Graphics Web Architecture

The three-tiered architecture of Developer/2000 for the Web enables you to
enhance your Web publications with interactive, data-driven graphic displays that
can be accessed from a remote application server by any client. You can leverage
this capability to embed powerful graphical applications directly in HTML pages,
or in Forms applications on the Web.

1.5.1 About the Graphics Client and Graphics Server

The Graphics Server consists of three componentsGraphics Web cartridge architec-
ture.

Figure 1–6 Graphics Server architecture

Graphics client
The Graphics client displays an interface that resembles the Graphics Builder Runt-
ime interface and allows you to run your existing Graphics applications without
modification on the Web. Any HTML Web browser running on any platform can
function as a Graphics client.
Web server with Oracle Web Request Broker module
The Web Request Broker™ is a separate module provided with Oracle WebServer
and supported by Netscape, Microsoft Web Server and others. The Web Request
Broker provides a framework for, and manages client connections to, cartridges
such as the Graphics Server.
Graphics Server
The Graphics Server is a variation of the Graphics runtime engine which runs on
the Web server and functions as an application server. When invoked by requests
or events submitted by the client and relayed through the Web Request Broker , the
Graphics Server processes the event, and returns an HTML page containing a refer-
ence an updated display image. The server communicates with the database
through SQL*Net (as it does in the traditional client-server implementation).

1.5.2 Call and response: Graphics client and Graphics cartridge

The Graphics client and Graphics Server communicate via an HTTP connection
through a series of requests and responses relayed through the Web Request Broker.

Understanding Developer/2000 for the Web 1-15

1.5 Graphics Web Architecture

Requests are initiated on the client side by direct URL submission, mouse-clicks in
the display region, or HTML-form submit requests. All requests are passed as one
of the following:
■ A simple URL
■ A parameterized URL containing special keyword arguments similar to those
used in Graphics Batch (for example, userids or values for user-defined parame-
ters).
Responses are returned as one of the following:
■ An HTML form functioning as a Graphics Web interface
■ An HTML form containing an image of the requested display
For more information about URL submission to the Graphics Server, see Section
1.5.3, “Running Graphics displays on the Web.”.

1.5.2.1 About display instances and session IDs

It is possible for multiple instances of a Graphics display to be open simultaneously
if:
■ A single user uses more than one browser to open multiple instances of a dis-
play at the same time.
■ Different users open the same display at the same time.
When multiple instances of a display are open, each instance of the display is
unique and independent. That is, when a user performs an action on one instance
of a display, other instances of the display are not affected.
The Graphics Server uses session IDs to identify instances of open displays. When
the server receives a request for a display, it generates a unique session ID repre-
senting the display instance, and embeds the ID in its initial response to the client.
The client returns the session ID as a parameter with any event it submits to the
server, thus identifying the instance of the display that is being referenced. Note
that the generation and submission of session IDs is an automatic process and
requires no attention from the end user or developer.

1.5.3 Running Graphics displays on the Web

Users can access a Graphics display on the Web by one of two methods:
■ Selecting it from a pull-down list on the Graphics Web interface toolbar.
■ Submitting a parameterized URL requesting the display.

1-16 Understanding Developer/2000 for the Web

 1.5 Graphics Web Architecture

The first method provides an efficient method for browsing through, and selecting
from, a list of displays. The second enables the user to use Graphics parameters
specifications to:
■ Embed Graphics displays in custom-HTML pages.
■ Execute PL/SQL code contained in displays.
■ Supply additional information (such as userids, or values for user-defined
parameters) in display requests.
■ Customize the Graphics Web toolbar.

1.5.3.1 Accessing Graphics displays via the Graphics Web interface toolbar
The easiest way to access a Graphics display is through the Graphics Web interface
toolbar. To use this method, the user points the web browser to the simple URL
that invokes the toolbar. For example:
http://my_server/ogweb
The following sequence then occurs:
6. The client passes the URL to the Web server.
7. The server’s Web Request Broker forwards the request to the Graphics Server.
8. The server returns an HTML-form that functions as the Graphics Web interface
toolbar.
9. On the toolbar, the user enters a username and password to connect to the data-
base, selects a display from the list of available displays, and clicks Open. This
causes the browser to submit a request in the form of a parameterized URL sim-
ilar to the following:
http://my_server/ogweb?openfile=my_display.ogd&userid=scott/
tiger@og73&my_parameter=my_value
10. The Web Request Broker forwards this request to the Graphics Server.

11. The server returns an HTML page containing the requested image.

12. Each time the user executes an event--for example, by clicking the mouse in a
display region--the client generates another request. Events are relayed via
automatically-generated parameterized URLs containing keywords describing
the details of the event (for example, mouse X and Y positions).

Understanding Developer/2000 for the Web 1-17

1.5 Graphics Web Architecture

1.5.3.2 Accessing Graphics displays via parameterized URLs

Users familiar with the standard keywords used to invoke Graphics Batch from a
command line can construct URLs containing the necessary parameters to access
Graphic displays directly from the server, rather than through the Graphics Web
toolbar. This method of accessing a display enables you to:
■ Embed Graphics displays in custom-HTML pages.
■ Execute PL/SQL code contained in displays.
■ Supply additional information (such as userids, or values for user-defined
parameters) in display requests.
■ Turn the Graphics Web interface toolbar on or off.
To accomplish any of the above, the user submits a parameterized URL. For exam-
ple:
http:/www.my_company.com/ogweb?openfile=my_display.ogd&userid=scott/
tiger@og73&oracle_interpret="BEGIN; MY-PROC(my_argument); END;"
The following sequence then occurs:
1. The client passes the URL to the Web server.
2. The server’s Web Request Broker forwards the request to the Graphics Server.
3. The server performs the operations specified by any additional keywords, and
returns an HTML page containing an image of the requested display.
4. Each time the user executes an event--for example, by clicking the mouse in a
display region--the client generates another request. Events are relayed via
additional, automatically-generated, parameterized URLs containing keywords
describing the details of the event (for example, mouse X and Y positions).
For more information about using Graphics command line options in parameter-
ized URLs, see Section 1.5.4, “About using Graphics parameters in URLs.”.

1.5.4 About using Graphics parameters in URLs

There are a number of Graphics keywords that can appear as ”name-value”pairs in
URLs used to invoke the Graphics Server. For example, a user might submit the fol-
lowing URL:
http://www.myserver.com/ogweb?openfile=mydisplay.ogd&userid=scott/
tiger@og73&showtoolbar=yes
This request employs the userid, openfile, and showtoolbar keywords to connect to a
database, open a display, and turn on the Graphics Web interface toolbar.

1-18 Understanding Developer/2000 for the Web

 1.5 Graphics Web Architecture

The following table defines the valid keywords and specifies the range of possible
values for each:

Keyword Use Valid values

openfile Specifies the name of the Graphics The name of any valid Graphics dis-
display file (.ogd) to open. play file. A suffix of ".ogd" or
".ogr" is assumed if not specified.
For example:
openfile=my_display.ogd
userid Specifies the full connect string to userid/password@dbname
log on to the desired database.
For example:
userid=scott/tiger@og73
showtoolbar Turns Graphics Web toolbar on or {yes|no}
off.
For example:
showtoolbar=yes
sessionid The unique identifier for the Any alpha-numeric session ID num-
instance of a Graphics display being ber generated by the Graphics
viewed via the Graphics Server. For Server.
more information about session IDs,
For example:
see Section 1.5.2.1, “About display
instances and session IDs.”. sessionid=000001.091032
close Closes the specified display. {yes}is the only valid value for the
close keyword.
Note: This keyword is necessary
only where strict control over docu- For example:
ments is required for security rea-
sessionid=000001.091032
sons, since by default the server
close=yes
automatically closes open displays
when the period specified in the
server parameter GW_TIMEOUT
has expired. For more information
about GW_TIMEOUT see Section
2.4.1, “Step 1: Creating the Graphics
Server cartridge entry in the Web
Request Broker.”.

Understanding Developer/2000 for the Web 1-19

1.5 Graphics Web Architecture

Note: All URL submissions to the Graphics Server must use the standard URL for-
mat of changing spaces to +, and encoding special characters with %xx hexadeci-
mal encoding. For more information about encoding URLs, see the W3C (World
Wide Web Consortium) document “Names and Addresses, URIs, URLs, URNs,
URCs” at http://www.w3.org/pub/WWW/Addressing/Addressing.html.

1-20 Understanding Developer/2000 for the Web