JetNet/Oracle Tuxedo Guide

With Panther, you can build client/server applications that comply with either a two-tier or three-tier architecture on multiple operating systems, including Windows and UNIX; you can also build fully functional web applications that run on the Internet or intranet. Inside the Panther framework, a development environment for Panther components allows shared access to libraries, and includes utilities to configure and manage middleware and server components.

Three-Tier Processing

The two-tier client/server model typically separates data from the logic of an application. In the three-tier or enhanced client/server model, the backend server is known as the resource manager, and is usually a database. The layer between client and backend server is the application server. The client is responsible for user interactions, and the application server is responsible for providing business-level services and interacting with the resource manager as needed.

Three-tier applications offer the following benefits:

• Reduced overhead per user — Because the application server performs most processing, client processes require fewer resources. For example, to query a database, a client needs to contain only enough code to gather user input and send its request and data to the application server, which contains the code and SQL libraries required for database interaction.

• Reduced overhead per interaction — By off-loading most processing onto the application server, the client is free to perform its job independently of actual interaction with the database. Database requests can be efficiently serialized, thereby reducing the interaction time required for each request.

• Distributed processing — Because the client is removed from application server processing, clients and servers can reside on different machines.

• Modular design — By separating clients from database interaction, the database is protected from client errors. Further, you can modify client and server processes without disturbing other parts of the application.

• Extensibility — As the application grows, client and server processes can be added to handle increased traffic or provide new functionality. New client nodes and server machines can be added as needed while the application runs.

Three-Tier Application Components

The configuration for a three-tier JetNet or Oracle Tuxedo application typically accounts for these application components:

• Clients that host user interaction and issue service requests. Clients can be one of two types: a non-workstation client (or local client) resides on a machine which is running an application server; a workstation client attaches to an application through its connection to an application machine.

  Panther screens provide the mechanism for user interaction and client processing. Client screens are stored in client libraries.

• Services that are invoked at runtime to handle service requests. Services are defined in JPL or C or Java and are typically grouped with service components; refer to Chapter 5, "Defining Services in JetNet and Oracle Tuxedo Applications." Service components and routines are stored in server libraries.

• The JIF, which specifies all the services and service groups that are available for a server to advertise. The JIF provides the mapping between a service and its service component and routine.

• Application servers that handle service requests from clients. Panther supports three types of application servers: standard servers, which advertise JIF-defined services; conversion servers, which handle service requests from client screens converted from a two-tier application; and file access servers, which provide developers shared access to libraries across the network.

  Application servers provide access to resource managers such as a database. Each server can be connected to one or more resource managers.

• A JetNet configuration file that defines properties for the application in general, and for participating machines and servers. When you start an application, Panther reads the configuration file to determine which servers to boot and on which machines. The configuration file is accessible through the JetNet manager. For more information, refer to Chapter 3, "Configuring the Enterprise."

• A bulletin board liaison process (BBL) that resides on each machine and maintains the addresses of servers and the services that they provide. In a multi-machine configuration, the master machine also contains the distinguished bulletin board (DBBL), which maintains information about all machines and servers.

Figure 1-1 shows how components of a Panther enterprise application interact in a single-machine configuration:

Figure 1-1 Interaction of components in a Panther enterprise application.

A Panther enterprise application typically works as follows:

1. During initialization, a server consults with the JIF to determine which services it needs to provide:

   • A server that is configured to provide all services reads all service definitions from the JIF.

   • A server that is initialized to provide services from a service group reads the services that are defined for that group.

     The initialized server advertises its services to the local bulletin board, which stores this information and the server's address.

2. When a client makes a service request, it consults the JIF to determine which data, if any, need to accompany the request and how to make the request. Panther then relays the request to the local bulletin board. Through the bulletin board data, the service request is matched to a specific server. This information is returned to the client.
3. The client sends its request to the server.
4. On receiving the service request, the server responds as follows:

   • Consults with the JIF to determine which routine and service component handles this service.

   • Finds the service component in the server library and uses it in order to process the request.

5. If the request requires database interaction, the server process provides the necessary SQL to query the database.
6. When the server finishes processing the request, it sends its reply to the client.

In the implementation shown earlier, all processing and client interaction takes place on the same machine. More typically, clients interact with an application from personal workstations. Each workstation is outside the JetNet configuration and communicates with the application over a network.

A server machine has two processes that enable workstation connections:

• A workstation listener (WSL) that intercepts requests to connect from workstation clients.

• A workstation handler (WSH) that manages all interaction between workstation clients and application servers.

The following figure shows an application that has two workstation client connections:

Figure 1-2 Three-tier configuration with workstation client connections

Workstation clients connect to the application in three steps:

1. The client connects to the server machine's workstation listener process through a known network address. The workstation listener returns the address of a workstation handler to the client.
2. The workstation listener process sends a message to the workstation handler, informing it of the connection request.
3. The workstation client connects to the workstation handler. All further communication between the client and the application takes place through the workstation handler.

The three-tier model can be expanded so that multiple server machines can participate in a single application. In this way, resources can be distributed to allow efficient throughput and avoid overburdening any one machine.

In a networked application, one host serves as the master machine; you can boot and shut down an application only from this machine. The master machine also has a DBBL, which coordinates among BBLs on all other machines including the master. All machines have a bridge process, which enables communication between them and the network.

Figure 1-3 diagrams a two-machine configuration that is enabled for workstation client connections. The data that users require on deposit data and loan data is split between the two sites; for example, a request for checking account data is directed to host 1, while a query on mortgages is directed to host 2. Host 1 is also the master machine:

Figure 1-3 System with multiple server machines.

Web Application Server

Panther web applications can be integrated into a three-tier, distributed processing model. In this model, 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.

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

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

For more information about web application development, refer to the Web Developer's Guide.

Panther Development Environment

Whether the applications that you build use a two-tier or three-tier processing model, Panther provides a distributed development environment that affords concurrent access to server libraries and repositories across the network. This can help give all members of your development team access to the same information and sets of standards via the file access server (devserv) in your distribution, which you can configure and manage through the JetNet manager (refer to page 3-19).

You can take advantage of Panther's built-in controls for monitoring multi-user access of shared libraries and their contents. You can also use features of your own source control management system. Panther provides an interface to SCCS and PVCS source code management systems. If you do not use or have one of these systems, Panther provides a default warning system for controlling concurrent access to shared application objects during the development process.

For more information about implementing configuration management, refer to page 10-4 in the Application Development Guide.

Administration Tools

In Panther software, a number of interactive and command-line utilities let you configure and manage a distributed development environment as well as a deployed three-tier and web application environment.

JetMan, the graphical JetNet Manager, integrates all the facilities you need to configure and manage the middleware component of a Panther application. With it, you create and edit a binary JetNet configuration file; this file specifies how to set up an application's clients and servers and configure their interaction.

The following command-line utilities are also provided:

• rb2asc converts a binary JetNet configuration file to ASCII and vice versa.

• rbboot starts a Panther application.

• rbconfig creates a JetNet configuration file.

• rblisten starts the listener process.

• rbshutdown shuts down a Panther application.

• monitor administers a running web application.