JetNet/Oracle Tuxedo Guide

When you design your application there are many factors to take into account. For instance:

• The number of users who will be connected to the database, and the frequency of access to that database.

• Complexity of the database access.

• And, the overall load on the database and response time when the load is at its peak.

In general, Panther is designed to help you build large, enterprise-wide applications that utilize multiple servers and distributed databases. But, you can also build simple client/server applications that operate on a one-server machine. However, as application needs become more complicated because more frequent access to the database is required, or the number of users increase, it's time to consider a multi-tier, enhanced client/server solution.

With the clnt2svr (client-to-server) utility, you can convert a two-tier application that uses the transaction manager to a three-tier, enterprise-wide application. This chapter describes:

• Requirements for running a converted application.

• How to enhance the functionality of a converted application.

Converting an Application from Two- to Three-Tier

The clnt2svr utility converts any two-tier JAM or Panther application that uses the transaction manager.

Before running the utility, make sure your two-tier client screens, or source, reside in a library. To store screens in a library, run formlib.

The clnt2svr utility creates a three-tier client library and a server library from a single source two-tier library. The utility makes two copies of each screen from the specified library and moves one of the copies to the new client library (cl.lib) and moves the other as a service component to the new server library (sv.lib). The source library remains unchanged and intact.

Property Settings

Certain property values are set on the copies while other properties that are pertinent only to a client screen are removed from the corresponding service component in order to avoid unnecessary processing on the server.

Three-tier Client Screens

The client screens in cl.lib have the Model property (under Transaction) set to jetrb1, the request broker transaction model. The client screens use the model to submit service requests to the server. The server is then responsible for the database interaction by the transaction manager.

Service Components

The service components in the sv.lib are stripped of the following screen-level property values (if they were set on the source client screen):

• JPL Procedures—The unnamed procedure is removed unless the -r option is used.

• Entry and Exit Functions.

• Menu and Menu Script Name.

• Pointer (cursor specification).

• Wallpaper Pixmap (screen background).

• Icon (image displayed when screen is iconified).

The following properties associated with widgets on service components are stripped of values or changed:

• Active, Inactive, and Armed Pixmap specifications are removed.

• Drop-Down Source for option menus/combo boxes is changed from External Screen to Constant Data since the lists do not need to be populated from an external screen.

Requirements for Running a Converted Application

The installed middleware transaction model handles the service requests made by the client in a converted application. The model uses a built-in service to pass the request to the database transaction model and thereby handle most database interactions. To begin using your newly converted application, you need to:

• Make sure a conversion server is running. This ensures that the built-in services are available to the new client screens and service components. Refer to page 3-26 for information on initializing a conversion server.

• Set SMFLIBS to include the new client library in the client environment and do the same on the server to include the new server library. This ensures that the libraries are open on start up of the application.

Ensuring Usability

Once you get your new application up and running, there are some things that you should note and consider, depending on the kinds of processing or specifications that existed in your two-tier application. For example:

• If your source two-tier client screens used Continue operations—such as First/Last Record—via push buttons or menu options, these types of operations will not function in the three-tier architecture.

• There is no support for any database processing that does not use the transaction manager; that is, if you made DBMS calls directly to the database in your two-tier processing, these database interactions are not moved from the client to the server. You will have to define a service to handle such processing (refer to the next section for information on enhancing a converted application) or ensure that the client has a direct connection to the database.

• In general, any processing your two-tier screens performed (JPL execution, validation, transaction manager event functions) should be reviewed to ensure that the processing is being performed appropriately and by the appropriate agent. Depending on the type of processing, you need to determine whether the processing is best carried out on the client or on the server. For example, data entry validation might best be performed on the client, while database validation might be better performed on the server by way of a service call.

• Partial commands are not supported. A partial command is one that specifies a table view parameter and therefore operates on a portion of the tree, but not for all linked table views on the screen. Because the server cannot determine or maintain the state of information from one service call to the next, there is no guarantee that two sequential requests will be processed by the same server. Partial commands must be handled by defining a new service (refer to the next section for information on enhancing a converted application).

• JPL (or C) programs that make runtime property changes to your two-tier client screen, particularly Transaction and/or Database properties, will not function as expected once you convert your application. In general, these changes are not propagated from the three-tier client screen to its corresponding service component. For example, if you change the Parent Table at runtime, the service component is not aware of this change and the results returned to the client may not be as predicted.

Enhancing a Converted Application

You can implement a custom service to handle specific types of database interactions by assigning services via the client screen's table view. When you provide a service property value and define the service in the JIF, your application can implement a service for individual operations. For example, your application can use the built-in service to handle SELECT and INSERT operations, but use a custom service to handle an UPDATE.

For information on creating services and service components, refer to page 5-1.

To implement a custom service:

• Define the services in the JIF (refer to page 24-1 in the Using the Editors for instructions on using the JIF editor).

• You can implement a custom service for each server view on a screen. To do this you would specify the service in the appropriate Service property for the server view's master (root) table view. You can specify Delete, Insert, Select, and Update Services.

• Ensure that a server is initialized that advertises the new services.