Setting Up a BEA Tuxedo Application

     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

Managing CORBA Interface Repositories

This topic, which is specific to BEA Tuxedo CORBA environments, includes the following sections:

Note: The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported in Tuxedo 9.x. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, etc. should only be used:
Note: Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

An Interface Repository contains the interface descriptions of the CORBA objects that are implemented within the BEA Tuxedo domain. Administration of the Interface Repository is done using tools specific to BEA Tuxedo CORBA servers. These tools allow you to create an Interface Repository, populate it with definitions specified in Object Management Group Interface Definition Language (OMG IDL), and then delete interfaces. You may need to configure the system to include an Interface Repository server by adding entries in the application's UBBCONFIG file.

For related programming information, see the CORBA Programming Reference.

 


Administration Considerations

As an administrator, you need to determine whether an Interface Repository is required. Not all systems require it. If an Interface Repository is required, you need to create and populate a repository database. The repository database is created and populated using the idl2ir command.

If an Interface Repository is required, you need to answer the following questions:

You can configure the system to have one or more Interface Repository servers. At least one Interface Repository server needs to be configured if any of the clients use Dynamic Invocation Interface (DII) .

There are two reasons to have more than one server: performance and fault tolerance. From a performance point of view, the number of Interface Repository servers is a function of the number of DII clients. From a fault tolerance point of view, the number of Interface Repository servers needed is determined by the configuration of the system, and the degree of failure protection required.

In systems with more then one Interface Repository server, you must decide whether to have replicated databases, shared databases, or a combination of the two. There are advantages and disadvantages to each configuration. Replicated Interface Repository databases allow for local file access that can potentially increase performance.

The main problem with replicated databases is updating them. All the databases must be identical and this requires the starting and stopping of Interface Repository servers. Having the Interface Repository database mounted and shared eliminates this problem, but this has performance implications and introduces a single point of failure. A combination of the two alternatives is also possible.

 


Using Administration Commands to Manage Interface Repositories

Use the following commands to manage the Interface Respository for a BEA Tuxedo domain:

Prerequisites

Before executing a command, you must ensure the bin directory is in your defined path, as follows:

On Windows:

set path=%TUXDIR%\bin;%path%

On UNIX:

For c shell (csh): set path = ($TUXDIR/bin $path)

For Bourne (sh) or Korn (ksh): PATH=$TUXDIR/bin:$PATH
export PATH

To set environment variables:

On Windows:

set var=value

On UNIX:

For c shell:

setenv var value

For Bourne and Korn (sh/ksh):

var=value
export var

Creating and Populating an Interface Respository

Use the idl2ir command to create an Interface Repository and load interface definitions into it. If no repository file exists, the command creates it. If the repository file does exists, the command loads the specified interface definitions into it. The format of the command is as follows:

idl2ir [options] definition-filename-list

For a detailed description of this command, see the File Formats, Data Descriptions, MIBs, and System Processes Reference in the BEA Tuxedo online documentation.

Note: If you want changes to be visible, you must restart the Interface Repository servers.

Displaying or Extracting the Content of an Interface Repository

Use the ir2idl command to display the content of an Interface Repository. You can also extract the OMG IDL statements of one or more interfaces to a file. The format of the command is as follows:

ir2idl [options] [interface-name]

For a detailed description of this command, see the File Formats, Data Descriptions, MIBs, and System Processes Reference in the BEA Tuxedo online documentation.

Deleting an Object from an Interface Repository

Use the irdel command to delete the specified object from the Interface Repository. Only interfaces not referenced from another interface can be deleted. By default, the repository file is repository.ifr. The format of the command is as follows:

irdel [-f repository-name] [-i id] object-name

For a detailed description of this command, see the File Formats, Data Descriptions, MIBs, and System Processes Reference in the BEA Tuxedo online documentation.

Note: If you want changes to be visible, you must restart the Interface Repository servers.

 


Configuring the UBBCONFIG File to Start One or More Interface Repository Servers

For each application that uses one or more Interface Repositories, you must start one or more of the Interface Repository servers provided by Tuxedo CORBA. The server name is TMIFRSVR.You can add one or more entries for TMIFRSVR to the SERVERS section of the application's UBBCONFIG file.

By default, the TMIFRSVR server uses the Interface Repository file repository.ifr in the first pathname specified in the APPDIR environment variable. You can override this default setting by specifying the -f filename option on the command-line options (CLOPT) parameter.

The following example shows a SERVERS section from a sample UBBCONFIG file. Instead of using the default file repository.ifr in the default directory ($APPDIR) where the application resides, the example specifies an alternate file and location, /usr/repoman/myrepo.ifr.

Note: Other server entries are shown in the following sample to emphasize that the order in which servers are started for BEA Tuxedo CORBA applications is critical. A BEA Tuxedo CORBA application will not boot if the order is changed.
Note: For more information, see the section Required Order in Which to Boot CORBA C++ Servers on page 3-61 in Creating the Configuration File.
Note: Notice that the TMIFRSVR Interface Repository server is the fifth server started.

*SERVERS

# Start the BEA Tuxedo System Event Broker
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1

# Start the NameManager (master)
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"

# Start the NameManager (slave)
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"

# Start the FactoryFinder (-F)
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"

# Start the interface repository server
TMIFRSVR
SRVGRP = SYS_GRP
SRVID = 5
RESTART=Y
MAXGEN=5
GRACE=3600
CLOPT="-A -- -f /usr/repoman/myrepo.ifr"

For a description of the TMIFRSVR -f filename parameter, refer to the File Formats, Data Descriptions, MIBs, and System Processes Reference. In addition to the CLOPT -f filename parameter, the TMIFRSVR parameter can contain other parameters (those that are not specific to the BEA Tuxedo system) in the SERVERS section of an application's UBBCONFIG configuration file.

See the section How to Create the SERVERS Section of the Configuration File on page 3-54 in Creating the Configuration File, for details about parameters such as SRVGRP, SRVID, RESTART, MAXGEN, and GRACE.


  Back to Top       Previous  Next