|
|
This topic includes the following sections:
This topic describes how to distribute applications in the WLE environment, using a CORBA application as an example. However, the concepts apply to EJB applications as well. For more information about EJB applications, see Scaling Tasks for Application Assemblers and Deployers.
This topic includes the following sections:
Why Distribute an Application?
Distributing an application enables you to select which parts of an application should be grouped together logically and where these groups should run. You distribute an application by creating more than one entry in the GROUPS
section of the UBBCONFIG
file, and by dividing application resources or tasks among the groups. Creating groups of servers enables you to partition a very large application into its component business applications, and to assure that each of these into logical components is of a manageable size and in an optimal location.
About Distributing an Application
Benefits of a Distributed Application
With the WebLogic Enterprise (WLE) system, you can use factory-based routing to distribute the processing of a particular CORBA interface across multiple server groups and, if desired, across multiple machines. This feature allows you to distribute the processing load, which can prevent the processing bottlenecks that occur when concurrent, resource-intensive applications compete for the available CPU, memory, disk I/O, and network resources. For an example of using factory-based routing, see Scaling with Factory-based Routing.
For more information about WLE scalability features, see Scaling WLE Applications.
A distributed application:
Characteristics of Distributing an Application
This topic includes the following sections:
Using Data-Dependent Routing (TUXEDO Servers Only)
Note: This topic applies to TUXEDO servers only.
Data-dependent routing is a mechanism whereby a service request is routed by a client (or a server acting as a client) to a server within a specific group based on a data value contained within the buffer that is sent. Within the internal code of a service call, BEA TUXEDO chooses a destination server by comparing a data field with the routing criteria it finds in the Bulletin Board shared memory.
For any given service, a routing criteria identifier can be specified in the SERVICES
section of the UBBCONFIG
file. The routing criteria identifier (in particular, the mapping of data ranges to server groups) is specified in the ROUTING
section.
Data-dependent routing has the following characteristics:
About Data-Dependent Routing
Characteristics of Data-Dependent Routing
Table 5-1 illustrates how client requests are routed to servers. In this example, a banking application called bankapp
uses data-dependent routing. For bankapp
, there are three groups (BANKB1
, BANKB2
, and BANKB3
), and two routing criteria (Account_ID
and Branch_ID
). The services WITHDRAW
, DEPOSIT
, and INQUIRY
are routed using the Account_ID
field. The services OPEN
and CLOSE
are routed using the Branch_ID
field.
Sample Distributed Application
Server Group |
Routing Criteria |
Services |
---|---|---|
This topic includes the following sections:
Configuring the UBBCONFIG File
For more information about the UBBCONFIG file, see "Creating a Configuration File" in the The UBBCONFIG
file contains a description of either data-dependent routing (BEA TUXEDO) or factory-based routing (WLE CORBA), as follows:
About the UBBCONFIG in Distributed Applications
Note: If a service has multiple entries, each with a different SRVGRP parameter, all such entries must set ROUTING the same way to ensure consistency for that service. A service can route only on one field, which must be the same for all the same services.
The parameters in the GROUPS
section implement two important aspects of distributed transaction processing:
Modifying the GROUPS Section
Table 5-2 describes the parameters in the GROUPS
section.
The SERVICES section contains parameters that control the way application services are handled. An entry line in this section is associated with a service by its identifier name. Because the same service can be link edited with more than one server, the SRVGRP parameter is provided to tie the parameters for an instance of a service to a particular group of servers. Three parameters in the SERVICES section are particularly related to DTP: ROUTING , AUTOTRAN , and TRANTIME .
Table 5-3 describes the parameters in the SERVICES section.
Parameter |
Meaning |
---|---|
Note: AUTOTRAN and TRANTIME apply to CORBA applications only. For EJB applications, the AUTOTRAN parameter is ignored and the transaction timeout is specified in the <trans-timeout-seconds> XML element in the weblogic-ejb-extensions.xml file. For more information, see "Transactions in EJB Applications" in
Using Transactions.The following listing shows a sample SERVICES section:
*SERVICES
WITHDRAW ROUTING=ACCOUNT_ID
DEPOSIT ROUTING=ACCOUNT_ID
OPEN_ACCT ROUTING=BRANCH_ID
For information about ROUTING parameters that support BEA TUXEDO data-dependent routing or the WLE factory-based routing, see "Creating a Configuration File" in the Administration Guide.
The following UBBCONFIG file contains the GROUPS , SERVICES , and ROUTING sections of a configuration file to accomplish data-dependent routing in the BEA TUXEDO system.
*GROUPS
BANKB1 GRPNO=1
BANKB2 GRPNO=2
BANKB3 GRPNO=3
#
*SERVICES
WITHDRAW ROUTING=ACCOUNT_ID
DEPOSIT ROUTING=ACCOUNT_ID
INQUIRY ROUTING=ACCOUNT_ID
OPEN_ACCT ROUTING=BRANCH_ID
CLOSE_ACCT ROUTING=BRANCH_ID
#
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE="FML"
RANGES="MIN - 9999:*,
10000-49999:BANKB1,
50000-79999:BANKB2,
80000-109999:BANKB3,
*:*"
BRANCH_ID FIELD=BRANCH_ID BUFTYPE="FML"
RANGES="MIN - 0:*,
1-4:BANKB1,
5-7:BANKB2,
8-10:BANKB3,
*:*"
For CORBA applications, to configure factory-based routing across multiple domains, you must configure the factory_finder.ini file to identify factory objects that are used in the current (local) domain but that are resident in a different (remote) domain. For more information, see "Configuring Multiple Domains (WLE System)" in the Administration Guide.
This topic includes the following sections:
This section is specific to BEA TUXEDO and explains how and why you need to modify the domain gateway configuration to support routing. For more information about the domain gateway configuration file, see "Configuring Multiple Domains (WLE System)" in the Administration Guide.
The Domain gateway configuration information is stored in a binary file called BDMCONFIG
. The DMCONFIG
file (ASCII) is created and edited with any text editor. The compiled BDMCONFIG
file can be updated while the system is running by using the dmadmin
(1) command.
You must have one BDMCONFIG
file for each BEA TUXEDO application that requires the Domains functionality. System access to the BDMCONFIG
file is provided through the Domains administrative server, DMADM
(5). When a gateway group is booted, the gateway administrative server, GWADM
(5), requests from the DMADM
server a copy of the configuration required by that group. The GWADM
server and the DMADM
server also ensure that run-time changes to the configuration are reflected in the corresponding Domain gateway groups.
Note:
For more information about modifying the DMCONFIG
file, see "Configuring Multiple Domains (WLE System)" in the Administration Guide.
The DM_ROUTING
section provides information for data-dependent routing of service requests using FML
, VIEW
, X_C_TYPE
, and X_COMMON
typed buffers. Lines within the DM_ROUTING
section have the form CRITERION_NAME
, where CRITERION_NAME
is the (identifier) name of the routing entry specified in the SERVICES section. The CRITERION_NAME
entry may contain no more than 15 characters.
Table 5-4 describes the parameters in the DM_ROUTING section.
About the Domain Gateway Configuration File
Parameters in the DM_ROUTING Section of the DMCONFIG File (TUXEDO Only)
The routing field can be of any data type supported in FML
or VIEW
. A numeric routing field must have numeric range values, and a string routing field must have string range values.
String range values for string, carray, and character field types must be placed inside a pair of single quotation marks and cannot be preceded by a sign. Short and long integer values are a string of digits, optionally preceded by a plus (+
) or minus (-
) sign. Floating point numbers are of the form accepted by the C compiler or atof()
: an optional sign, followed by a string of digits optionally containing a decimal point, and an optional e
or E
followed by an optional sign or space, and an integer.
When a field value matches a range, the associated RDOM
value specifies the remote domain to which the request should be routed. An RDOM
value of *
indicates that the request can go to any remote domain known by the gateway group. Within a range/RDOM
pair, the range is separated from the RDOM
by a :
(colon).
The following configuration file defines a five-site domain configuration. Listing 5-1 shows four bank branch domains communicating with a Central Bank Branch. Three of the bank branches run within other BEA TUXEDO system domains. The fourth branch runs under the control of another TP domain, and OSI-TP is used in the communication with that domain. The example shows the BEA TUXEDO Domain gateway configuration file from the Central Bank point of view. In the DM_TDOMAIN
section, this example shows a mirrored gateway for b01
.
Listing 5-1
DMCONFIG File for a Five-Site Domains Configuration
# BEA TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK Routing Field Description
Example of a Five-Site Domain Configuration Using Routing
#
#
*DM_LOCAL_DOMAINS
# <local domain name> <Gateway Group name> <domain type> <domain id> <log device>
# [<audit log>] [<blocktime>]
# [<log name>] [<log offset>] [<log size>]
# [<maxrdom>] [<maxrdtran>] [<maxtran>]
# [<maxdatalen>] [<security>]
# [<tuxconfig>] [<tuxoffset>]
#
#
DEFAULT: SECURITY = NONE
c01 GWGRP = bankg1
TYPE = TDOMAIN
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C01"
c02 GWGRP = bankg2
TYPE = OSITP
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C02"
NWDEVICE = "OSITP"
URCH = "ABCD"
#
*DM_REMOTE_DOMAINS
#<remote domain name> <domain type> <domain id>
#
b01 TYPE = TDOMAIN
DOMAINID = "BA.BANK01"
b02 TYPE = TDOMAIN
DOMAINID = "BA.BANK02"
b03 TYPE = TDOMAIN
DOMAINID = "BA.BANK03"
b04 TYPE = OSITP
DOMAINID = "BA.BANK04"
URCH = "ABCD"
#
*DM_TDOMAIN
#
# <local or remote domainname> <network address> [nwdevice]
#
# Local network addresses
c01 NWADDR = "//newyork.acme.com:65432" NWDEVICE ="/dev/tcp"
c02 NWADDR = "//192.76.7.47:65433" NWDEVICE ="/dev/tcp"
# Remote network addresses: second b01 specifies a mirrored gateway
b01 NWADDR = "//192.11.109.5:1025" NWDEVICE = "/dev/tcp"
b01 NWADDR = "//194.12.110.5:1025" NWDEVICE = "/dev/tcp"
b02 NWADDR = "//dallas.acme.com:65432" NWDEVICE = "/dev/tcp"
b03 NWADDR = "//192.11.109.156:4244" NWDEVICE = "/dev/tcp"
#
*DM_OSITP
#
#<local or remote domain name> <apt> <aeq>
# [<aet>] [<acn>] [<apid>] [<aeid>]
# [<profile>]
#
c02 APT = "BA.CENTRAL01"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.3},{1}"
ACN = "XATMI"
b04 APT = "BA.BANK04"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.4},{1}"
ACN = "XATMI"
*DM_LOCAL_SERVICES
#<service_name> [<Local Domain name>] [<access control>] [<exported svcname>]
# [<inbuftype>] [<outbuftype>]
#
open_act ACL = branch
close_act ACL = branch
credit
debit
balance
loan LDOM = c02 ACL = loans
*DM_REMOTE_SERVICES
#<service_name> [<Remote domain name>] [<local domain name>]
# [<remote svcname>] [<routing>] [<conv>]
# [<trantime>] [<inbuftype>] [<outbuftype>]
#
tlr_add LDOM = c01 ROUTING = ACCOUNT
tlr_bal LDOM = c01 ROUTING = ACCOUNT
tlr_add RDOM = b04 LDOM = c02 RNAME ="TPSU002"
tlr_bal RDOM = b04 LDOM = c02 RNAME ="TPSU003"
*DM_ROUTING
# <routing criteria> <field> <typed buffer> <ranges>
#
ACCOUNT FIELD = branchid BUFTYPE ="VIEW:account"
RANGES ="MIN - 1000:b01, 1001-3000:b02, *:b03"
*DM_ACCESS_CONTROL
#<acl name> <Remote domain list>
#
branch ACLIST = b01, b02, b03
loans ACLIST = b04
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|