JetNet/Oracle Tuxedo Guide

Appendix B. Converting to a Three-tier Application

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

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:

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):

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

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:

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:

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: