The Server Dialog and Server entities

The purpose of these entities is to develop and generate the server-side components of client/server graphic or texutal applications.

The Server Dialog is a logical envelope that groups the various server components of an application.

In the Server Dialog, you give the general characteristics of the application. You specify the generation variants and options that apply by default to all the attached components.

Two basic types of architecture are possible: one that uses a monitor, and the other that does not.

The Business Component

A Business Component supports a set of services on a Logical View.

These services can be generic and dedicated to selections and updates on a Logical View. They can also be specific and support functional requirements.

The Business Component must complete the processing for the selection, check, and update services that are requested by the Logical Views. This processing includes the following tasks:
  • Accessing the external resources (files, databases),
  • Completing checks and updates,
  • Completing specific processing (calculations, extraction methods, and so forth),
  • Managing the errors.

Generic services are independent of the storage medium that is used to manage their persistence.

A Business Component then describes the relations between a Logical View and the persistence objects that are used to select or update its instances.

The Server Monitor

The Server Monitor is reserved for textual applications. It completes the following tasks:
  • Receives the information that is sent by the client through the communication area,
  • Calls the Server that corresponds to the service requested by the client,
  • Returns the information to the Client Monitor.

The Communication Monitor

The Communication Monitor is reserved for graphic applications. It completes the following tasks:
  • Handles the communication functions (message sending and receiving) according to the target environment.
    Note: If an application is run on different environments, there must be as many Communication Monitors as there are environments. Several communication protocols can be used for the same environment (for example, CICS ECI and CICS CPIC).
  • Checks each received message.
  • Sends and receives the query.
    Note: According to the size that is allowed for the physical message, several physical messages can be created to obtain the complete logical message. A work file must therefore be available for the temporary storage of the current query.
  • Sequentially processes the services that are included in the query.
  • Manages the transaction (COMMIT/ROLLBACK).

    The Communication Monitor uses the COMMIT and ROLLBACK services of a database or of a transactional monitor, depending on its generation variant.

    The server part runs a COMMIT or a ROLLBACK, according to the error context (protocol error or application error) established at the end of the query processing. If an error occurs, the query processing is stopped and an error message is sent. All the resources that are used by the query processing are then made available after the response has been sent.

The Error Message Server

The Error Message Server generates the messages of the errors that are detected by the Business Components. These messages are stored in a dedicated generated file.

The Initialization and Termination Business Component

An Initialization and Termination Business Component implements specific processing before and after the running of a request.

An Initialization and Termination Business Component is called before the first call to the Business Component that is associated with the request and after the last Business Component.

It is available either for an initialization or for a termination process.

For an initialization process, only the data that is sent by the client component through the user buffers can be processed in input.

Therefore, the generation of an Initialization and Termination Business Component contains the access functions and PERFORM instructions of the services that are associated with the Business Components.

Generation

For explanations on the contents of the generated code, see COBOL description of a generated Server.

Note: For the instances that are imported from Pacbase, the skeleton language of the local generation is identical to the Pacbase skeleton language. This piece of information is retrieved from the extraction of the Pacbase models and from the import. It is stored in the Library.

Feedback