لطفا منتظر باشید ...
9.2 OracleAS Forms Services
For many years, OracleAS Forms Services has been one of
the most popular 4GL development environments for Oracle database
applications. OracleAS Forms Services was designed originally to be
closely integrated with the Oracle database. As we mentioned,
OracleAS Forms Services uses
PL/SQL as the language for its
extended logic. The same Oracle sales team that provided the Oracle
database was also able to helpfully supply this development tool.
But, as the technology environment evolved, OracleAS Forms Services
was caught in a bind. Like many client-server tools, OracleAS Forms
Services split the runtime functionality of its applications between
the client and the server.The new environment of Internet computing required a slightly
different deployment model. To address this new requirement, the
OracleAS Forms Services development team created a new deployment
model in 1997 with Release 4.1. In
this new model, a Java applet talks to a Java servlet on a server.
That server, in turn, calls the OracleAS Forms Services runtime. With
this new deployment model, OracleAS Forms Services deployment was
transformed from a two-tier client-server architecture into a
three-tier web-based architecture.
9.2.1 How It Works
The interaction between a web client and an Oracle
Forms application through OracleAS
Forms Services is shown in simplified form in Figure 9-1.
Figure 9-1. Simplified OracleAS Forms Services architecture
instance, with a URL that indicates an Oracle Forms application. The
Oracle HTTP Server instance forwards the URI request through
mod_oc4j
to the Oracle Forms servlet, which is run in an OC4J instance.The Oracle Forms servlet starts by creating some HTML, based on the
application and the browser type. This HTML is passed to the Oracle
Forms Listener servlet.The Oracle Forms Listener servlet passes the HTML back to the client.
The servlet also creates an Oracle Forms runtime process (written in
C) for the application.The HTML passed to the client starts the client-side applet and
spawns a client request for a particular form.Once the connection between the Oracle Forms Listener and the client
is established, further interaction between the client and the
runtime process is done through the Oracle Forms Listener servlet. At
this point, the Oracle Forms servlet is no longer needed.
A single Oracle Forms Listener servlet can manage communications
between multiple clients and their runtime processes.Developers can still use the familiar Oracle Forms development
environment, but they now deploy Oracle Forms applications as
browser-based clients connecting over the Internet or an intranet to
a middle tier of Oracle Application Server. This new architecture
also brings other features with it, as we explain in subsequent
sections.OracleAS Forms Services applications use a default HTML template to
pass environment variables to the browser, but you can also create
your own templates by modifying the default template to include
either hardcoded values for parameters or dynamic parameters from the
Oracle Forms configuration file.
9.2.2 Running Oracle Forms Services Applications
Once you create an application in Oracle Forms
Developer, it can be deployed through OracleAS Forms Services. You
have to create a configuration for the application either manually or
through a portion of the Oracle Enterprise Manager
10g Application Server Control tool (described
in Chapter 3). For more information on using
Oracle Enterprise Manager to manage OracleAS Forms Services, see Section 9.2.3.When a user wants to run an OracleAS Forms Services application, the
interaction proceeds as follows, from the user's
point of view:The user sends a URL (containing the pathname) to the Oracle Forms
servlet. This URL also contains the name of the configuration file or
the name of a section of the configuration file.Based on the configuration file, the Oracle Forms servlet returns an
HTML page, which is specific for the type of browser being used by
the client.The HTML page loads a client-side applet, which runs in a JVM on the
client.
|
a JVM to run properly. Because the native JVM on a particular browser
may not be appropriate, Oracle supplies a client-side plug-in called
Oracle JInitiator. Oracle JInitiator allows the use of an alternative
JVM to run the client-side Oracle Forms applet as a plug-in to
Netscape Navigator or Microsoft Internet Explorer.Some parts of a particular form are common across all users accessing
that form, such as screen definitions and application logic. Once
these parts are loaded for a form, subsequent users of the same form
can share these entities in memory, with only their private
application data requiring its own dedicated memory.The architecture for OracleAS Forms Services is different from the
standard client-server architecture, and that fact has implications
for the performance of applications. In the multitier OracleAS Forms
Services environment, the limiting performance factor is frequently
the bandwidth from the client to the middle tier. For this reason,
OracleAS Forms Services applications optimize the communications
between the client and the middle tier. For instance, OracleAS Forms
Services applications bundle events together after each navigation
event. These event bundles interact between the OracleAS Forms Server
and the back-end database without having to communicate with the
client applet.Although each individual user has a OracleAS Forms Services runtime
process, you can have multiple instances of OracleAS Forms Services.
Because the Oracle Forms servlets are standard OC4J applications, you
can use any of the normal load-balancing options for OC4J for these
Oracle Forms Listeners.You can create a pool of runtime engines for a particular application
in the configuration file for the application. The runtime engines in
this pool service users for the application. You can configure a
number of instances to be started when an administrator starts the
application from Application Server Control, as we discuss in the
following section.
9.2.3 Managing OracleAS Forms Services
The Application Server Control tool lets
you set parameters to control the operation of an OracleAS
Forms
Services application. For example, you can control the look and feel
of the client portion of the application or the specific title of a
particular HTML page returned to the client. The configuration file
can also be used to provide different versions of the same
application in different languages.For most parameters, you can override the value in the configuration
file by including the parameter in the URL that calls the OracleAS
Forms Services application. You can also specify parameters that
can't be overridden for a particular application in
this configuration file.Oracle Enterprise Manager gives you an easy
interface for managing the underlying configuration files used by
OracleAS Forms Services. You can still manually edit these files, but
after making changes, you will have to stop all the DCM processes, as
well as Oracle Enterprise Manager, to have the changes recognized by
Oracle Enterprise Manager. If you don't do this, any
subsequent changes made through Oracle Enterprise Manager will simply
overwrite the manually changed configuration files.You can have multiple configurations in separate sections of the
configuration file. You might want to do this if different users have
different versions of the OracleAS Forms Services application.Many different parameters shape the appearance and behavior of your
OracleAS Forms Services application. A comprehensive list of these
parameters is beyond the scope of this book. Please refer to the
OracleAS Forms Services documentation for more information.The portion of Application Server Control that handles OracleAS Forms
Services can be used to limit access to OracleAS Forms Services. You
can disallow any new user connections to these services on a
particular server, or you can kill specific user sessions.
9.2.4 Configuring Security
OracleAS Forms Services can be
configured to use the OracleAS Single Sign-On capability of Oracle
Application Server without additional code. In Oracle Application
Server, OracleAS Single Sign-On uses the identity management that is
based on the Oracle Internet Directory. Although Oracle Forms
applications have traditionally used a database username and password
for security, the Oracle Forms Listener servlet can take this
information and use the Oracle Internet Directory to implement
OracleAS Single Sign-On with an OracleAS
Forms Services application. Because the handling of OracleAS Single
Sign-On is done by the OracleAS Forms servlets, not in the Oracle
Forms Runtime Process, existing Oracle Forms applications can take
advantage of OracleAS Single Sign-On without any modification. In
fact, the form itself is unaware of whether OracleAS Single Sign-On
was used, although the form can acquire this information if your
logic requires it.You can create user accounts with connect information in the Oracle
Internet Directory, which in turn creates
Resource Access Descriptors
(RADs) once a user connects to OracleAS Forms Services. As of the
Oracle Application Server 10g release, you can
configure OracleAS Forms Services to allow all users to create their
own RADs on the fly if none exists; previous releases returned an
error in such cases. Also new in Oracle Application Server
10g is the fact that updating a password in the
database automatically updates the RAD information in the Oracle
Internet Directory.
