|
•
|
Replicating the ORA_GRP and APP_GRP server groups on an additional server machine, Production Machine 2, and also partitioning the database.
|
To increase scalability, the Registrar and
Teller objects are configured in the Production server application with the
method activation policy. The
method activation policy assigned to these two objects results in the following behavior changes:
With the Basic through the Wrapper sample applications, the Registrar object was process-bound (
process activation policy). All client requests on the
Registrar object invariably went to the same object instance in the memory of the server machine. The Basic sample application design may be adequate for a small-scale deployment. However, as client application demands increase, client requests on the
Registrar object eventually become queued, and response time drops.
However, when the Registrar and
Teller objects are stateless (
method activation policy), and the server processes that manage these objects are replicated, the
Registrar and
Teller objects can process multiple client requests in parallel. The only constraint on the number of simultaneous client requests that these objects can handle is the number of server processes that are available that can instantiate the
Registrar and
Teller objects. These stateless objects, thereby, make for more efficient use of machine resources and reduced client response time.
Figure 2‑1 shows the replicated
ORA_GRP and
APP_GRP groups running on a single machine.
Figure 2‑2 shows the Production sample application groups replicated on another machine, as specified in the application’s
UBBCONFIG file, as
ORA_GRP2 and
APP_GRP2.
In Figure 2‑2, the only difference between the content of the groups on Production Machines 1 and 2 is the database:
Listing 2‑1 shows excerpts from the
GROUPS and
SERVERS sections of the
UBBCONFIG file for the Production sample application.
|
•
|
Requests from client applications to the Registrar object are routed based on the student ID. Requests from student ID 100001 to 100005 go to Production Machine 1. Requests from student ID 100006 to 100010 go to Production Machine 2.
|
|
•
|
Requests from the Registrar object to the Teller object are routed based on account number. Billing requests for account 200010 to 200014 go to Production Machine 1. Billing requests for account 200015 to 200019 go to Production Machine 2.
|
The UBBCONFIG file must specify the following data in the
INTERFACES and
ROUTING sections, as well as how groups and machines are identified.
|
1.
|
The INTERFACES section lists the names of the interfaces for which you want to enable factory-based routing. For each interface, this section specifies the kinds of criteria on which the interface routes. This section specifies the routing criteria via an identifier, FACTORYROUTING, as shown in Listing 2‑2.
|
Listing 2‑2 shows the fully qualified interface names for the two interfaces in the Production sample in which factory-based routing is used. The
FACTORYROUTING identifier specifies the names of the routing values, which are
STU_ID and
ACT_NUM, respectively.
|
2.
|
The ROUTING section specifies the parameters in Table 2‑1 for each routing value.
|
Listing 2‑3 shows the
ROUTING section of the
UBBCONFIG file used in the Production sample application.
Listing 2‑3 shows that
Registrar object references for students with IDs in one range are routed to one server group, and
Registrar object references for students with IDs in another range are routed to another group. Likewise,
Teller object references for accounts in one range are routed to one server group, and
Teller object references for accounts in another range are routed to another group.
|
3.
|
The groups specified by the RANGES identifier in the ROUTING section of the UBBCONFIG file need to be identified and configured. For example, the Production sample specifies four groups: APP_GRP1, APP_GRP2, ORA_GRP1, and ORA_GRP2. These groups need to be configured, and the machines on which they run need to be identified.
|
Listing 2‑4 shows the
GROUPS section of the Production sample
UBBCONFIG file, in which the
ORA_GRP1 and
ORA_GRP2 groups are configured. Notice how the names in the
GROUPS section match the group names specified in the
RANGES parameter in the
ROUTING section. This is critical for factory-based routing to work correctly. Furthermore, any change in the way groups are configured in an application must be reflected in the
ROUTING section. (Note that the Production sample packaged with the Oracle Tuxedo software is configured to run entirely on one machine. However, you can easily configure this application to run on multiple machines.)
The third parameter to this operation, criteria, specifies a list of named values to be used for factory-based routing. To implement factory-based routing in a factory, you need to build the
NVlist. The use of factory-based routing is optional and is dependent on this argument. Instead of using factory-based routing, you can pass a value of
0 (zero) for this argument.
As stated previously, the RegistrarFactory object in the Production sample application specifies the value
STU_ID. This value must exactly match the following information in the
UBBCONFIG file:
The RegistrarFactory object inserts the student ID into the
NVlist using the code shown in
Listing 2‑6.
The RegistrarFactory object has the invocation to the
TP::create_object_reference() operation, shown in
Listing 2‑7, passing the
NVlist created in
Listing 2‑6.
|
2.
|
The RegistrarFactory inserts the student ID into an NVlist, which is used as the routing criteria.
|
|
3.
|
The RegistrarFactory invokes the TP::create_object_reference() operation, passing the Registrar interface name, a unique OID, and the NVlist.
|
|
•
|
The Registrar and Teller objects work properly for the Production deployment environment; namely, across multiple replicated server processes and multiple groups. Given that the University and Billing server processes are replicated, the design must consider how these two objects should be instantiated.
|
To make each Registrar and
Teller object unique, the factories for those objects must change the way in which they make object references to them. For example, when the
RegistrarFactory object in the Basic sample application created an object reference to the
Registrar object, the
TP::create_object_reference() operation specified an OID that consisted only of the string
registrar. However, in the Production sample application, the same
TP::create_object_reference() operation uses a generated unique OID instead.
As a result of giving each Registrar and
Teller object a unique OID, multiple instances of these objects may be running simultaneously in the Oracle Tuxedo domain. This characteristic is typical of the stateless object model, and is an example of how the Oracle Tuxedo domain can be highly scalable while it offers high performance.
Finally, because unique Registrar and
Teller objects need to be brought into memory for each client request on them, it is critical that these objects be deactivated when the invocations on them are completed so that any object state associated with them does not remain idle in memory. The Production server application addresses this issue by assigning the
method activation policy to these two objects in the Implementation Configuration File (ICF).
For example, when the client application sends a request to the RegistrarFactory object to get an object reference to a
Registrar object, the client application includes a student ID in that request. The client application must use the object reference that the
RegistrarFactory object returns to make all subsequent invocations on a
Registrar object on a particular student’s behalf, because the object reference returned by the factory is group-specific. Therefore, for example, when the client application subsequently invokes the
get_student_details() operation on the
Registrar object, the client application can be assured that the
Registrar object is active in the server group associated with the database containing data for that student.
|
3.
|
The RegistrarFactory object uses the student ID to create an object reference to a Registrar object in ORA_GRP1, based on the routing information in the UBBCONFIG file, and returns that object reference to the client application.
|
The RegistrarFactory object from the preceding scenario returns to the client application a unique reference to a
Registrar object that can be instantiated only in
ORA_GRP1, which runs on Production Machine 1 and has a database containing student data for students with IDs in the range
100001 to
100005. Therefore, when the client application sends subsequent requests to this
Registrar object on behalf of a given student, the
Registrar object interacts with the correct database.
When the Registrar object needs a
Teller object, the
Registrar object invokes the
TellerFactory object, using the
TellerFactory object reference cached in the University Server object.
However, because factory-based routing is used in the TellerFactory object, the
Registrar object passes the student’s account number when the
Registrar object requests a reference to a
Teller object. This way, the
TellerFactory object creates a reference to a
Teller object in the group that has the correct database.
