|
|
|
|
|
|
Before you begin, be sure to read Scaling WLE Applications, for a comprehensive introduction to tuning and scaling WebLogic Enterprise (WLE) applications. For more information about the JDBC Bankapp sample application, see "The JDBC Bankapp Sample Application" in the Guide to the Java Sample Applications.
Note:
Some of the Bankapp examples in this topic include sample code that is not implemented in the product sample's Bankapp files.
This topic includes the following sections:
About Scaling the JDBC Bankapp Sample Application
The primary design goal of the JDBC Bankapp sample application is to significantly increase the number of client applications it can accommodate by:
Design Goals
To accommodate these design goals, the JDBC Bankapp sample application has been scaled by:
How the Application Has Been Scaled
This makes these objects available on a per-client application (and not per-process) basis, thereby accommodating a parallel processing capability.
The sections that follow describe how the JDBC Bankapp sample application uses replicated server processes and server groups, object state management, and factory-based routing to meets it scalability goals.
This section describes how object state management is used with the Teller
objects in the Bankapp sample application to increase the application's scalability. For an introduction to object state management, see Using Object State Management.
For example, the Bankapp sample Teller
object could use the method
activation policy. The method
activation policy assigned to this object means that the object is activated whenever a client request arrives for it. The Teller
object remains in memory only for the duration of one client invocation, which is appropriate in cases where the Process-Entity design pattern is recommended. For more information about the Process-Entity design pattern, see the technical article Process-Entity Design Pattern.
As the number of clients issuing requests on the Teller
object increases, WLE can:
Scaling with Object State Management
This topic includes the following sections:
Scaling by Replicating Server Processes and Server Groups
This topic describes how the BankApp server application was scaled by replicating server processes and server groups. For an introduction to this topic, see Replicating Server Processes and Server Groups.
Figure 3-1 shows the Bankapp server application replicated in the BANK_GROUP1
group. The replicated servers are running on a single machine.
When a request arrives for this group, WLE has several server processes available that can process the request, and WLE can choose the server process that is the least busy.
In Figure 3-1, note the following:
Replicating Server Processes in the Bankapp Application
Figure 3-1 Replicated Servers in the Bankapp Sample
Figure 3-2 shows the Bankapp sample application groups replicated on another machine, as specified in the application's UBBCONFIG
file.
Note:
In the simple example shown in Figure 3-2, the content of the databases on Production Machines 1 and 2 is identical. Each database contains all of the account records for all of the account IDs. Only the processing is distributed, based on the ATM (atmID
field). A more realistic example would distribute the data and processing based on ranges of bank account IDs.
For more information about how the Bankapp sample application uses factory-based routing to distribute the application's processing load across multiple machines, see Scaling with Factory-based Routing.
The following example shows excerpts from the GROUPS
and SERVERS
sections of the UBBCONFIG
file for a Bankapp sample application.
Note:
These configuration settings are not used with the Bankapp sample provided with the WLE software.
*RESOURCES *MACHINES *GROUPS *SERVERS *SERVICES *INTERFACES *ROUTING This topic includes the following sections:
Replicating Server Groups in the Bankapp Application
Figure 3-2 Replicating Server Groups Across Machines
Configuring Replicated Server Processes and Groups in the Bankapp Application
IPCKEY 55432
DOMAINID simple
MASTER SITE1
MODEL SHM
LDBAL Y
"TRIXIE"
LMID = SITE1
APPDIR = "c:\bankapp\jdbc\."
TUXCONFIG = "c:\bankapp\jdbc\.\tuxconfig"
TUXDIR = "c:\m3dir"
MAXCLIENTS = 10
SYS_GRP
LMID = SITE1
GRPNO = 1
BANK_GROUP1
LMID = SITE1
GRPNO = 2
BANK_GROUP2
LMID = SITE1
GRPNO = 3
# By default, restart a server if it crashes, up to 5 times
# in 24 hours.
#
DEFAULT:
RESTART = Y
MAXGEN = 5
# Start the Tuxedo System Event Broker. This event broker
# must be started before any servers providing the
# NameManager Service.
#
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
# TMFFNAME is a M3 provided server that runs the
# object-transactional management services. This includes the
# NameManager and FactoryFinder services.
# The NameManager service is a M3-specific service
# that maintains a mapping of application-supplied names to
# object references.
# Start the NameManager Service (-N option). This name
# manager is being started as a Master (-M option).
#
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
# Start a slave NameManager Service
#
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
# Start the FactoryFinder (-F) service
#
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -N -F"
# Start the JavaServer in Bank_Group1
#
JavaServer
SRVGRP = BANK_GROUP1
SRVID = 5
CLOPT = "-A -- -M 10 BankApp.jar TellerFactory_1"
SYSTEM_ACCESS=FASTPATH
RESTART = N
# Start the JavaServer in Bank_Group2
#
JavaServer
SRVGRP = BANK_GROUP2
SRVID = 6
CLOPT = "-A -- -M 10 BankApp.jar TellerFactory_1"
SYSTEM_ACCESS=FASTPATH
RESTART = N
# Start the listener for IIOP clients
#
# Specify the host name of your server machine as
# well as the port. A typical port number is 2500
#
ISL
SRVGRP = SYS_GRP
SRVID = 7
CLOPT = "-A -- -n //TRIXIE:2468"
"IDL:beasys.com/BankApp/Teller:1.0"
FACTORYROUTING=atmID
atmID
TYPE = FACTORY
FIELD = "atmID"
FIELDTYPE = LONG
RANGES = "1-5:BANK_GROUP1,
6-10: BANK_GROUP2,
*:BANK_GROUP1Scaling with Factory-based Routing
This topic describes how the BankApp server application was scaled using factory-based routing. For an introduction to factory-based routing, see Using Factory-based Routing (CORBA only).
You can use factory-based routing to expand WLE's load-balancing and scalability features. In the Bankapp sample application, you can use factory-based routing to send requests to a subset of ATMs to one machine, and requests for another subset of ATMs to another machine. As you increase your application's processing capability, you can easily modify the factory-based routing in your application to add more machines.
The primary design consideration regarding implementing factory-based routing in the Bankapp sample application is in choosing the value on which routing is based. The following sections describe how factory-based routing works in the JDBC Bankapp sample application. Client application requests to the Teller
object are routed based on a teller number:
About Factory-based Routing in the Bankapp Application
The UBBCONFIG
file must specify the following data in the INTERFACES
and ROUTING
sections, as well as how groups and machines are identified:
Configuring Factory-based Routing in the UBBCONFIG File
*INTERFACES
"IDL:beasys.com/BankApp/Teller:1.0"
FACTORYROUTING = atmID
The preceding example shows the fully qualified Interface Repository ID for an interface in the extended Bankapp sample in which factory-based routing is used. The FACTORYROUTING identifier specifies the name of the routing value, atmID .
Table 3-1 Parameters Specified in the ROUTING
Section
Parameter
Description
The following example shows the ROUTING section of the UBBCONFIG file used in the Bankapp sample application:
*ROUTING
atmID
TYPE = FACTORY
FIELD = "atmID"
FIELDTYPE = LONG
RANGES = "1-5:BANK_GROUP1,
6-10: BANK_GROUP2,
*:BANK_GROUP1
The preceding example shows that Teller object references for ATMs in one range are routed to one server group, and Teller object references for ATMs in other ranges are routed to other groups. As shown in Figure 3-2, BANK_GROUP1 and BANK_GROUP2 reside on different production machines.
Factories implement factory-based routing in the way in which the invocation to the com.beasys.Tobj.TP.create_object_reference method is implemented.
This operation has the following Java binding:
public static org.omg.CORBA.Object
create_object_reference(java.lang.String interfaceName,
java.lang.String stroid,
org.omg.CORBA.NVList criteria)
throws InvalidInterface,
InvalidObjectId
The criteria specifies a list of named values that can be used to provide factory-based routing for the object reference. 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. To implement factory-based routing in a factory, you need to build the NVlist .
As stated previously, the TellerFactory object in the Bankapp sample application specifies the value atmID . This value must exactly match the following information in the UBBCONFIG file:
Note: The following example is not part of the Bankapp sample code, but is included here to illustrate factory-based routing. The TellerFactory object inserts the bank account number into the NVlist using the following code:
// Put the atmID (which is the routing criteria)
// into a CORBA NVList. The atmID comes from the
// tellerName that is passed in as an input parameter;
// tellerName should have the form: Teller<atmID>
int atmID = Integer.parseInt (tellerName.substring(6));
any.insert_long(atmID);
// Create the NVlist and add the atmID to the list.
org.omg.CORBA.NVList criteria = TP.orb().create_list(1);
criteria.add_value("atmID", any, 0);
// Create the object reference.
org.omg.CORBA.Object teller_oref =
TP.create_object_reference(
BankApp.TellerHelper.id(), // Repository ID
tellerName, // Object ID
criteria // Routing Criteria
);
When you implement factory-based routing in a factory, WLE generates an object reference. The following example shows how the client application gets an object reference to a Teller
object when factory-based routing is implemented:
What Happens at Run Time
When the client application subsequently invokes an object using the object reference, WLE routes the request to the group specified in the object reference.
Note: If you use the process-entity design pattern, you should use caution in how you implement factory-based routing. The object can service only those entities that are contained in the group's database.
This topic includes the following sections:
When designing the Teller
object, you should ensure that:
About the Additional Design Considerations
These objects must have unique object IDs (OIDs) and must be method-bound (that is, they must have the method
activation policy assigned to them).
Because the extended Bankapp server is now replicated, the WLE domain must have be able to differentiate among multiple instances of the Teller
object. For example, if there are two Bankapp server processes running in a group, WLE must be able to distinguish between a Teller
object running in the first Bankapp server process and a Teller
object running in the second Bankapp server process. To distinguish multiple instances of these objects, each object instance must be unique.
To make each Teller
object unique, the factories for those objects must change the way in which they make object references to them. For example, when the TellerFactory
object in the original Bankapp sample application created an object reference to the Teller
object, the com.beasys.Tobj.TP::create_object_reference
method specified an OID that consisted only of the string tellerName
. However, in the extended Bankapp sample application discussed in this chapter, the same create_object_reference
method uses a generated unique OID instead.
As a result of giving each Teller
object a unique OID, multiple instances of these objects may be running simultaneously in the WLE domain. This characteristic is typical of the stateless object model, and is an example of how the WLE domain can be highly scalable while it offers high performance.
Finally, because unique 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 Bankapp server application addresses this issue by assigning the method
activation policy to the Teller
object in the XML-based Server Description File.
The primary scalability advantage of using replicated server groups is being able to distribute processing across multiple machines. However, if your application interacts with a database, which is the case with the JDBC Bankapp sample application, it is critical that you consider the impact of these multiple server groups on the database interactions.
In many cases, you may have one database associated with each machine in your deployment. If your server application is distributed across multiple machines, you must consider how you set up your databases.
The JDBC Bankapp sample application uses factory-based routing to send one set of requests to one machine, and another set to the other machine. How factory-based routing is implemented in the TellerFactory
object depends on how references to Teller
objects are created.
In the future, the system administrator of the Bankapp sample application may want to add capacity to the WLE domain. For example, the bank may eventually have a large increase in automated teller machines (ATMs). This can be done without modifying or rebuilding the application.
The system administrator can continually add capacity by:
Instantiating the Teller Object
Ensuring That Account Updates Occur in the Correct Server Group
Scaling the Application Further
The system administrator must modifying the UBBCONFIG file to specify the additional groups, the server processes that run in those groups, and the machines on which they run.
For example, instead of routing to the four groups shown earlier in this chapter, the system administrator can modify the routing rules in the UBBCONFIG file to partition the application further among the new groups added to the WLE domain. Any modification to the routing tables must be consistent with any changes or additions made to the server groups and machines configured in the UBBCONFIG file.
Note: If you add capacity to an application that uses a database, you must also consider the impact on how the database is set up, particularly when you are using factory-based routing. For example, if the Bankapp sample application is distributed across six machines, the database on each machine must be set up appropriately and in accordance with the routing tables in the UBBCONFIG file.
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|