Scaling, Distributing, and Tuning CORBA Applications

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Distributing CORBA Applications

This topic includes the following sections:

This topic describes how to distribute applications in the Oracle Tuxedo CORBA environment, using a CORBA application as an example.

Notes: The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.
Note: Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

 


Why Distribute an Application?

This topic includes the following sections:

About Distributing 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.

Benefits of a Distributed Application

The benefits of a distributed application include:

Characteristics of Distributing an Application

A distributed application:

 


Using Data-dependent Routing (Oracle Tuxedo ATMI Servers Only)

This topic includes the following sections:

Note: This topic applies to Oracle Tuxedo servers only.

About Data-dependent Routing

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, Oracle 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.

Characteristics of Data-dependent Routing

Data-dependent routing has the following characteristics:

Sample Distributed Application

Table 3-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.

Table 3-1 Data-dependent Routing Criteria for Sample Distributed Application 
Server Group
Routing Criteria
Services
BANKB1
Account_ID: 10000 - 49999
WITHDRAW, DEPOSIT, and INQUIRY
Branch_ID: 1 - 4
OPEN and CLOSE
BANKB2
Account_ID: 50000 - 79999
WITHDRAW, DEPOSIT, and INQUIRY
Branch_ID: 5 - 7
OPEN and CLOSE
BANKB3
Account_ID: 80000 - 109999
WITHDRAW, DEPOSIT, and INQUIRY
Branch_ID: 8 - 10
OPEN and CLOSE

Example of UBBCONFIG Sections in a Distributed Application

Listing 3-1 shows a sample UBBCONFIG file that contains the GROUPS, SERVICES, and ROUTING sections of a configuration file to accomplish data-dependent routing in the Oracle Tuxedo system.

Listing 3-1 Sample UBBCONFIG File
*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,
                        *:*”

 


Configuring the UBBCONFIG File

This topic includes the following sections:

For more information about the UBBCONFIG file, see “Creating a Configuration File” in Setting Up an Oracle Tuxedo Application .

About the UBBCONFIG File in Distributed Applications

The UBBCONFIG file contains a description of either data-dependent routing (Oracle Tuxedo) or factory-based routing (Oracle Tuxedo CORBA), as follows:

Modifying the GROUPS Section

The parameters in the GROUPS section implement two important aspects of distributed transaction processing:

Table 3-2 describes the parameters in the GROUPS section.

Table 3-2 Parameters Specified in the GROUPS Section 
Parameter
Meaning
LMID
LMID must be assigned in the MACHINES section to indicate that this server group runs on this particular machine. A second LMID value can be specified (separated from the first by a comma) to name an alternate machine to which this server group can be migrated if the MIGRATE option has been specified. Servers in the group must specify RESTART=Y to migrate.
GRPNO
Associates a numeric group number with this server group. The number must be greater than zero (0) and less than 30000. It must be unique among entries in the GROUPS section in this configuration file. (Required)
TMSNAME
Specifies which transaction management server (TMS) should be associated with this server group.
TMSCOUNT
Specifies how many copies of TMSNAME should be started for this server group. The minimum value is 2. If not specified, the default is 3. All TMSNAME servers started for a server group are automatically set up in an MSSQ set. (Optional)
OPENINFO
Specifies information needed to open a particular instance of a particular resource manager, or it indicates that such information is not required for this server group. When a resource manager is named in the OPENINFO parameter, information such as the name of the database and the access mode is included. The entire value string must be enclosed in double quotes and must not be more than 256 characters. The format of the OPENINFO string is dependent on the requirements of the vendor providing the underlying resource manager. The string required by the vendor must be prefixed with rm_name:, which is the published name of the vendor's transaction (XA) interface followed immediately by a colon (:).
The OPENINFO parameter is ignored if TMSNAME is not set or is set to TMS. If TMSNAME is set but the OPENINFO string is set to the null string ("") or if this parameter does not appear on the entry, it means that a resource manager exists for the group but does not require any information for executing an open operation.
CLOSEINFO
Specifies information the resource manager needs when closing a database. The parameter can be omitted or the null string can be specified. The default is the null string.

Modifying the SERVICES 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.

Parameters to Modify

Two parameters in the SERVICES section are particularly related to distributed transaction processing (DTP) for Oracle Tuxedo CORBA applications that use Oracle Tuxedo ATMI services: AUTOTRAN, and TRANTIME.

Table 3-3 describes the parameters in the SERVICES section.

Table 3-3 Parameters Specified in the SERVICES Section 
Parameter
Meaning
AUTOTRAN
Determines whether a transaction should be started automatically if a message received by this service is not already in transaction mode.The default is N. Use of the parameter should be coordinated with the programmers that code the services for your application.
TRANTIME
Specifies a timeout value, in seconds, for transactions automatically started in this service. The default is 30 seconds. Required only if AUTOTRAN=Y and another timeout value is needed.

Sample SERVICES Section

Listing 3-2 shows a sample SERVICES section.

Listing 3-2 Production Sample SERVICES Section
*SERVICES
    # Publish Tuxedo Teller application services
#
DEBIT
AUTOTRAN=Y
CREDIT
AUTOTRAN=Y
CURRBALANCE
AUTOTRAN=Y

Modifying the INTERFACES Section

The INTERFACES section contains parameters that control the way application interfaces are handled. An entry line in this section is associated with an interface by its identifier name. Because the same interface can be link edited with more than one server, the SRVGRP parameter is provided to tie the parameters for an instance of a interface to a particular group of servers.

Parameters to Modify

Three parameters in the INTERFACES section are particularly related to distributed transaction processing (DTP): FACTORYROUTING, AUTOTRAN, and TRANTIME.

Table 3-4 describes the parameters in the INTERFACES section.

Table 3-4 Parameters Specified in the INTERFACES Section 
Parameter
Meaning
FACTORYROUTING = criterion-name
Specifies the name of the routing criteria to be used for factory-based routing for this Oracle Tuxedo CORBA interface. You must specify a FACTORYROUTING parameter for interfaces requesting factory-based routing.
AUTOTRAN
Determines whether a transaction should be started automatically if a message received by this interface is not already in transaction mode.The default is N. Use of this parameter should be coordinated with the programmers that code the interface for your application so that it matches the setting of the transaction policy option in the application’s ICF file.
TRANTIME
Specifies a timeout value, in seconds, for transactions automatically started in this interface. The default is 30 seconds. Required only if AUTOTRAN=Y and a timeout value other than the default is needed.
LOAD = number
Specifies an arbitrary number between 1 and 100 that represents the relative load that the CORBA interface is expected to impose on the system. The numbering scheme is relative to the LOAD numbers assigned to other CORBA interfaces used by this application. The default is 50. This number is used by the Oracle Tuxedo system to select the best server to which to route the request

Sample INTERFACES Section

Listing 3-3 shows a sample INTERFACES section.

Listing 3-3 Sample INTERFACES Section
*INTERFACES
  "IDL:beasys.com/UniversityP/Registrar:1.0"
        FACTORYROUTING = STU_ID
        AUTOTRAN=Y
        TRANTIME=50

  "IDL:beasys.com/BillingP/Teller:1.0"
        FACTORYROUTING = ACT_NUM
        AUTOTRAN=Y

Creating the ROUTING Section

For information about ROUTING parameters that support Oracle Tuxedo data-dependent routing or Oracle Tuxedo CORBA factory-based routing, see “Creating a Configuration File” in Setting Up an Oracle Tuxedo Application .

Listing 3-4 shows the ROUTING section of the UBBCONFIG file used in the Production sample application for factory-based routing.

Listing 3-4 Production Sample ROUTING Section
*ROUTING

   STU_ID
      FIELD = "student_id"
      TYPE = FACTORY
      FIELDTYPE = LONG
      RANGES = "100001-100005:ORA_GRP1,100006-100010:ORA_GRP2"

   ACT_NUM
      FIELD = "account_number"
      TYPE = FACTORY
      FIELDTYPE = LONG
      RANGES = "200010-200014:APP_GRP1,200015-200019:APP_GRP2"

 


Configuring the factory_finder.ini (CORBA Applications Only)

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 Multiple Domains for CORBA Applications in Using the Oracle Tuxedo Domains Component .

 


Modifying the Domain Gateway Configuration File to Support Routing

This topic includes the following sections:

This section is specific to Oracle 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 Multiple Domains for CORBA Applications in Using the Oracle Tuxedo Domains Component .

About the Domain Gateway Configuration File

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 Oracle 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 Multiple Domains for CORBA Applications” in Using the Oracle Tuxedo Domains Component.

Parameters in the DM_ROUTING Section of the DMCONFIG File (Oracle Tuxedo ATMI Only)

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.

Parameters to Specify

Table 3-5 describes the parameters in the DM_ROUTING section.

Table 3-5 Parameters Specified in the DM_ROUTING Section 
Parameter
Description
FIELD = identifier
Specifies the name of the routing field. It must contain 30 characters or fewer. This field is assumed to be a field name identified in an FML field table (for FML buffers) or an FML VIEW table (for VIEW, X_C_TYPE, or X_COMMON buffers). The FLDTBLDIR and FIELDTBLS environment variables are used to locate FML field tables; the VIEWDIR and VIEWFILES environment variables are used to locate FML VIEW tables. If a field in an FML32 buffer is used for routing, it must have a field number less than or equal to 8191.
BUFTYPE = "type1[:subtype1[,subtype2 . . . ]][;type2[:subtype3[, . . . ]]] . . ."
Specifies list of types and subtypes of data buffers for which this routing entry is valid. The types are restricted to FML, VIEW, X_C_TYPE, and X_COMMON.
No subtype can be specified for type FML, and subtypes are required for the other types (* is not allowed).
Duplicate type/subtype pairs cannot be specified for the same routing criteria name; more than one routing entry can have the same criteria name as long as the type/subtype pairs are unique. This parameter is required.
If multiple buffer types are specified for a single routing entry, the data types of the routing field for each buffer type must be the same. (If the field value is not set (for FML buffers), or does not match any specific range, and a wildcard range has not been specified, then an error is returned to the application process that requested the execution of the remote service.) No routing is allowed on CORBA and EJB (TGIOP is not a valid buffer type).
RANGES ="range1:rdom1[,range2:rdom2 ...]"
Specifies the ranges and associated remote domain names (RDOM) for the routing field. The string must be enclosed in double quotes, with the format of a comma-separated ordered list of range/RDOM pairs.
A range is either a single value (signed numeric value or character string in single quotes), or a range of the form lower - upper (where lower and upper are both signed numeric values or character strings in single quotes). The value of lower must be less than or equal to upper. A single quote embedded in a character string value (such as “O'Brien”), must be preceded by two backslashes (“O\\'Brien”).
  • Use MIN to indicate the minimum value for the data type of the associated FIELD. For strings and carrays, it is the null string; for character fields, it is 0; for numeric values, it is the minimum numeric value that can be stored in the field.
  • Use MAX to indicate the maximum value for the data type of the associated FIELD. For strings and carrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field.
Thus, MIN - -5 is all numbers less than or equal to -5, and 6 - MAX is all numbers greater than or equal to 6.
The metacharacter * (wildcard) in the position of a range indicates any values not covered by the other ranges previously seen in the entry. Only one wildcard range is allowed per entry and it should be last (ranges following it are ignored).

Routing Field Description

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

Example of a Five-Site Domain Configuration Using Routing

Listing 3-5 shows a configuration file that defines a five-site domain configuration. It has four bank branch domains communicating with a Central Bank Branch. Three of the bank branches run within other Oracle 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 Oracle 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 3-5 DMCONFIG File for a Five-Site Domains Configuration
# BEA TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK
#
#
*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

  Back to Top       Previous  Next