BEA WebLogic Enterprise 4.2    Developer Center     

        HOME   |   SITE MAP   |   SEARCH   |   CONTACT   |   GLOSSARY  |   PDF FILES |   WHAT'S NEW 
 
        Administration    |   TABLE OF CONTENTS   |   PREVIOUS TOPIC   |   NEXT TOPIC   |   INDEX 

Administrative Reference (WLE System)

The WLE system supports the following administrative commands and server processes:

This chapter describes these commands and processes.

idl2ir

Synopsis

Creates the Interface Repository and loads interface definitions into it.

Syntax

idl2ir [options] definition-filename-list

Options

The options are as follows:

[-f repository-name] [-c]
[-D identifier[=definition]]
[-I pathname [-I pathname] [...]] [-N{i|e}]

Description

Use this command to create the Interface Repository and to load it with interface definitions. If no repository file exists, this command creates it. If a repository file does exist, this command loads the specified interface definitions into it and, in effect, updates the file.

One of the side effects of doing this is that a new Interface Repository database file is created.

Parameters

definition-filename-list
A list of file specifications containing the repository definitions. These files are treated as one logical file and are loaded in one operation.

-f repository-name
The filename of the Interface Repository file. If you do not specify the -f option, the idl2ir command creates repository.ifr as the Interface Repository file on UNIX systems and repository_1.ifr on Microsoft Windows NT systems.

-c
Indicates that a new repository is to be created. If a repository exists and this option is specified, the idl2ir command ignores the existing repository and replaces it with a new one. If a repository exists and this option is not specified, the idl2ir command updates the existing repository.

-D identifier[=definition]
Performs the same function as the #define preprocessor directive; that is, the -D option defines a token string or a macro to be substituted for every occurrence of a given identifier in the definition file. If a definition is not specified, the identifier is defined as 1.You can specify multiple -D options.

-I pathname
Specifies a directory within which to search for include files, in addition to any directories specified with the #include OMG IDL preprocessor directive.

There are two types of #include OMG IDL preprocessor directives: system (for example, <a.idl>) and user (for example, "a.idl"). The path for system #include directives is /usr/include for UNIX systems, and any directories specified with the -I option. The path for system #include directives is the local directory for Windows NT systems, and any directories specified with the -I option.

The path for user #include directives is the current directory and any directories specified with the -I option. Multiple -I options can be specified.

ir2idl

Synopsis

Shows the contents of an Interface Repository.

Syntax

ir2idl [options] [interface-name]

Options

The options are as follows:

[-f repository-name] [-n]
[-t interface-type] [-o filename]

Description

This command shows the contents of an Interface Repository. By directing the output to a file with the -o option, you can extract the OMG IDL file from the repository. By default, the repository file is repository.ifr.

Parameters

interface-name
The name of the interface whose contents are to be shown. If you do not specify an interface name, all interfaces in the repository are shown.

-f repository-name
The name of the repository to search for the interface definitions. If you do not specify the -f option, repository.ifr is used.

-n
Specifies that the output should not include those objects that were inherited.

-t interface-type
Indicates the type of objects to display. The object type must be one of the following keywords:
Attribute
Constant
Exception
Interface
Method
Module
Operation
Typedef
If you do not specify this option, the default is to display all of the types.

-o filename
The file specification for the file in which to write the retrieved OMG IDL statements. The default is standard output.

irdel

Synopsis

Deletes the specified object from an Interface Repository.

Syntax

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

Description

This command deletes the specified interface from the repository. Only interfaces not referenced from another interface can be deleted. By default, the repository file is repository.ifr.

Parameters

-f repository-name
An optional parameter that specifies an Interface Repository. The repository-name value is the file specification of an Interface Repository. If this option is not specified, the repository.ifr is used as the default.

-i id
The repository id for the specified object. The id is used as a secondary level of lookup. If the id does not match the id of the named object, the object is not deleted.

object-name
The name of the interface to delete from the repository. The name can be a simple object name or a scoped name, for example, MOD1::INTERF2::OP3 (operation OP3 is within interface INTERF2, which is in application MOD1).

ISL

Synopsis

Enables access to WLE objects by remote WLE clients using IIOP.

Syntax

ISL SRVGRP="identifier"

SRVID="number"

CLOPT="[ -A ] [ servopts options ] -- -n netaddr
[ -C {detect|warn|none} ]
[ -d device ]
[ -K {client|handler|both|none} ]
[ -m minh ]
[ -M maxh ]
[ -T Client-timeout]
[ -x mpx-factor ]
[-H external-netaddr]
#NEW options for Outbound IIOP
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users]"

Description

The IIOP Server Listener (ISL) is a WLE-supplied server command that enables access to WLE objects by remote WLE clients using IIOP. The application administrator enables access to the application objects by specifying the IIOP Server Listener as an application server in the SERVERS section. The associated command-line options are used to specify the parameters of the IIOP Server Listener and IIOP Server Handlers.

The location, server group, server ID, and other generic server-related parameters are associated with the ISL using the standard configuration file mechanisms for servers. ISL command-line options allow for customization.

Each ISL booted as part of an application facilitates application access for a large number of remote WLE clients by providing access via a single, well-known network address. The IIOP Server Handlers are started and stopped dynamically by the ISL, as necessary, to meet the incoming load.

For joint client/servers, if the remote joint client/server ORB supports bidirectional IIOP connections, the ISL can use the same inbound connection for outbound invokes to the remote joint client/server. The ISL also allows outbound invokes (outbound IIOP) to objects located in a joint client/server that is not connected to an ISH. This capability is enabled when the -O option is specified. The associated command-line options (those shown above in boldface text) allow configuration of outbound IIOP support:

Parameters

-A
Indicates that the ISL is to be booted to offer all its services. This is a default, but it is shown to emphasize the distinction between system-supplied servers and application servers. The latter can be booted to offer only a subset of their available services. The double-dash (--) marks the beginning of parameters that are passed to the ISL after it has been booted.

You specify the following options in the CLOPT string after the double-dash (--) in the CLOPT parameters:

-n netaddr
Specifies the network address to be used by a server listener to accept connections from remote CORBA clients. The remote client must set the environment variable (TOBJADDR) to this value, or specify the value in the Bootstrap object constructor. See the C++ Programming Reference for details. This is the only required parameter.
TCP/IP addresses must be specified in one of the following two formats:
"//hostname:port_number"
"//#.#.#.#:port_number"
In the first format, the domain finds an address for hostname using the local name facilities (usually DNS). The host must be the local machine, and the local name resolution facilities must unambiguously resolve hostname to the address of the local machine.

Note: The hostname must begin with a letter character.

In the second format, the "#.#.#.#" is the dotted decimal format. In dotted decimal format, each # must be a number from 0 to 255. This dotted decimal number represents the IP address of the local machine.
In both of the above formats, port_number is the TCP port number at which the domain process listens for incoming requests. port_number can be a number between 0 and 65535 or a name. If port_number is a name, it must be found in the network services database on your local machine.

Note: The Java Tobj_Bootstrap object uses a short type to store the port_number. Therefore, you must use a port_number in the range of 0 to 32767 if you plan to support connections from Java clients.

Note: The network address that is specified by programmers in the Bootstrap constructor or in TOBJADDR must exactly match the network address in the application's UBBCONFIG file. The format of the address as well as the capitalization must match. If the addresses do not match, the call to the Bootstrap constructor will fail with a seemingly unrelated error message:

ERROR: Unofficial connection from client at
<tcp/ip address>/<port-number>:

For example, if the network address is specified as //TRIXIE:3500 in the ISL command line option string, specifying either //192.12.4.6:3500 or //trixie:3500 in the Bootstrap constructor or in TOBJADDR will cause the connection attempt to fail.

On UNIX systems, use the uname -n command on the host system to determine the capitalization used. On Windows NT systems, see the host system's Network control panel to determine the capitalization used.

Note: Unlike the BEA TUXEDO system Workstation Listener (WSL), the format of the network addresses is limited to //host:port. The reason for this limitation is that the host name and port number are used by WLE servers; the host name does not appear as such in the hexadecimal format, and it could only be passed to the servers using the dotted IP address format.

[-C detect|warn|none]
Determines how the IIOP Listener/Handler will behave when unofficial connections are made to it. The default value is detect.
The official way for the CORBA client to connect to the IIOP Listener/Handler is via a Bootstrap object. The unofficial connection is established directly from an IOR. For example, a client could connect to one IIOP Listener/Handler via a Bootstrap object and then, perhaps inadvertently, connect to a second IIOP Listener/Handler by using an IOR that contains the host and port of the second IIOP Listener/Handler. Typically, this is not the case. Usually, the client uses IORs that contain the host and port of the IIOP Listener/Handler that the client connected to via a Bootstrap object. Use of such IORs does not cause an additional connection to be made.

Caution: The use of unofficial connections can cause problems for remote client applications that use transactions. The application may have the notion that invocations on both the official and unofficial connections within the same transaction have succeeded; however, in reality, only invocations on the official connection are ACID (Atomicity, Consistency, Isolation, and Durability).

A value of detect causes the ISL/ISH to raise a NO_PERMISSION exception when an unofficial connection is detected. A value of warn causes the ISL/ISH to log a message to the user log exception when an unofficial connection is detected; no exception will be raised. A value of none causes the ISL/ISH to ignore unofficial connections.

[-d device]
Specifies the device filename used for network access by the server listener and its server handlers. This parameter is optional because some transport providers (for example, sockets) do not require a device name. However, other providers (for example, TLI) do require a device name. In the case of TLI, this option is mandatory. There is no default for this parameter. (This does not apply to Windows NT systems.)

[-K {client|handler|both|none}]
Directs the client, or the ISH process, or both, to activate the network provider's KEEPALIVE option. This option improves the speed and reliability of network failure detection by actively testing an idle connection's state at the protocol stack level. The availability and timeout thresholds for this feature are determined by operating system tunable parameters.
A value of client configures this option for the client; a value of handler configures this option for the ISL; and a value of both will configure both sides of the connection. The default value is none, in which case neither side has the KEEPALIVE option configured.

Note: The KEEPALIVE interval is an operating system parameter, so changing the value affects any other applications that enable KEEPALIVE. Many platforms have a two-hour default value that may be longer than desired.

This option is not available on all platforms. A userlog warning message is generated if the KEEPALIVE option is specified but is not available on the ISH's machine. If KEEPALIVE is requested but is not available on the client's machine, the setting is ignored.

[-m minh]
Specifies the minimum number of handlers that should be available in conjunction with this ISL at any given time. The default is 0. The The ISL will start this many ISHs immediately upon being booted and will not deplete the supply of ISHs below this number until the administrator issues a shutdown to the ISL. The default value for this parameter is 0. The legal range is between 0 and 255.

[-M maxh]
Specifies the maximum number of handlers that should be available in conjunction with this ISL at any given time. The Handlers are started as necessary to meet the demand of remote WLE clients attempting to access the system. The default value for this parameter is equal to the setting for MAXWSCLIENTS on the logical machine, divided by the multiplexing factor for this ISL (see -x option below), rounded up by one. The legal range for this parameter is between 1 and 4096. The value must be equal to or greater than minh.

[-T Client-timeout]
Allows more time for a client to join an application when there is a large number of clients attempting to join simultaneously. The value is multiplied by the SCANUNIT parameter. The default is 3 in a nonsecure application and 6 in a secure application. For information about SCANUNIT, see the section "Characteristics of the SCANUNIT, SANITYSCAN, and BLOCKTIME Parameters" on page 3-19.

[-x mpx-factor]
This is an optional parameter used to control the degree of multiplexing desired within each ISH. The value for this parameter indicates the number of remote WLE clients that can be supported simultaneously by each ISH. The ISH ensures that new handlers are started as necessary to handle new remote WLE clients. This value must be greater than or equal to 1 and less than or equal to 4096. The default value for this parameter is 10.

[-H external netadder]
Specifies the external network address to be set as the host and port in interoperable object references returned to clients of the ISL. It has the same format as the ISL CLOPT -n netaddr option. This feature is useful when an IIOP, or remote, client needs to connect to an ISL through a firewall.

[-O]
This option (uppercase letter O) enables outbound IIOP to objects that are not located in a client that is connected to an ISH. Since the -O option requires a small amount of extra resources, the default is to not allow outbound IIOP.

[-o outbound-max-connections]
This option (lowercase letter o) specifies the maximum number of outbound connections that each ISH may have. In effect, it limits the number of simultaneous Outbound IIOP sockets that any single ISH under the control of this ISL will have active at one time.
This option requires that the -O (uppercase letter O) option is also specified. The value of this option must be greater than 0, but not more than 4096. An additional requirement is that the value of this option, (outbound-max-connections) times the maximum number of handlers, must be less than 32767. The default for this option is 20.

[-s Server-timeout]
Server-timeout is the time, in minutes, allowed for a remote server to remain idle. If a remote server does not receive any requests within this time period, the ISL disconnects the outbound IIOP connection to the server. The ISH reconnects to the remote server on subsequent requests. This option can be used for server platforms that are unstable. Note that this is a best-attempt value in that the ISL does not disconnect the connection before this time is up, but does not guarantee to disconnect the connection once the exact time has elapsed. This option requires that the -O (uppercase letter O) option is also specified. The value must be greater than or equal to 1. If this option is not specified, the default is 60 (one hour).

[-u out-mpx-users]
An optional parameter used to control the degree of outbound multiplexing desired within each ISH. The value for this option indicates the number of outbound IIOP users (native clients or servers) that can be supported simultaneously by each outbound IIOP connection in the ISH. The ISL ensures that new ISHs are started, as necessary, to handle new users up to the value of this option (out-mpx-users). This option requires that the -O (uppercase letter O) option is also specified. This option must be greater than 0 (zero), but not more than 1024; the default value is 10.

Portability

The IIOP Server Listener is supported as a WLE-supplied server on UNIX and Microsoft Windows NT operating systems.

Interoperability

The ISL works with any IIOP compliant ORB.

Network Addresses

Suppose the local machine on which the ISL is being run is using TCP/IP addressing and is named backus.company.com, with address 155.2.193.18. Further suppose that the port number at which the ISL should accept requests is 2334. The address specified by the -l option could be:

//155.2.193.18:2334

//backus.company.com:2334

Examples

*SERVERS

ISL SRVGRP="ISLGRP" SRVID=1002 RESTART=Y GRACE=0

CLOPT="-A -- -n //piglet:1900 -d /dev/tcp"

See Also

UBBCONFIG(5)

TMFFNAME

Synopsis

Server that runs the FactoryFinder and supporting NameManager services.

Syntax

TMFFNAME SRVGRP="identifier" SRVID="number"
[CLOPT="[-A] [servopts options]
[-- [-F ] [-N | -N -M [-f filename]]]"]

Description

TMFFNAME is a server provided by WLE that runs the FactoryFinder and supporting NameManager services which maintain a mapping of application-supplied names to object references.

Parameters

-A
Advertise all services built into the server

-F
FactoryFinder service

-N
Slave NameManager service
This is the default.

-M
Master NameManager service

-f filename
Location of FactoryFinder import file

The FactoryFinder service is a CORBA-derived service that provides client applications with the ability to find application factories that correspond to application-specified search criteria. Consult the C++ Programming Reference for a complete description on the FactoryFinder API and Creating C++ Server Applications for a description of registering and unregistering factories. The FactoryFinder service is the "default" service if no services are specified in the CLOPT.

The NameManager service is a WLE-specific service that maintains a mapping of application-supplied names to object references. One usage of this service is to maintain the application factory name-to-object reference list. The NameManager service can be booted with an -M option that designates a Master role. If the -M option is not specified, the NameManager is assumed to be a Slave. Slave NameManagers obtain updates from the Master. Only one Master NameManager can be specified in an application.

The master NameManager can be configured to support the location of factory objects that reside in a remote domain through the use of an initialization file (for example import_factories.ini). The location of the initialization file is specified with the -f command-line option. If the -f option is not specified, the Master NameManager will search the directory specified by the APPDIR environment variable for a file with the name factory_finder.ini. If the file is not found, the Master NameManager will continue initialization, but will be unable to locate factory objects in domains other than the local one.

Note: It is possible to boot one or more TMFFNAME processes running the same service. To provide increased reliability, at least two NameManager services must be configured, preferably on different machines.

Interoperability

The TMFFNAME servers run on WLE version 4.0 software and later.

Notes

If there are less than two NameManager services configured in the application's UBBCONFIG (TMFFNAME -N), the server terminates itself during boot and writes an error message to the user log.

If a Master NameManager service is not configured in the application's UBBCONFIG file and is running when a Slave NameManager service starts, the server terminates itself during boot and writes an error message to the user log. Additionally, if the Master is down, registration and unregistration of factories is disabled until the Master restarts.

If a TMSYSEVT server is not configured in the application's UBBCONFIG file and is not running when a NameManager service is being started, the server terminates itself during boot and writes an error message to the user log.

If a NameManager service is not configured in the application's UBBCONFIG file and a FactoryFinder service is being started, the server terminates itself during boot and writes an error message to the user log.

Example

*SERVERS
TMSYSEVT SRVGRP=ADMIN1 SRVID=44 RESTART=Y
CLOPT="-A"

TMFFNAME SRVGRP=ADMIN1 SRVID=45 RESTART=Y
CLOPT="-A -- -F"

TMFFNAME SRVGRP=ADMIN1 SRVID=46 RESTART=Y
CLOPT="-A -- -N -M -f c:\appdir\import_factories.ini"
TMFFNAME SRVGRP=ADMIN2 SRVID=47 RESTART=Y
CLOPT="-A -- -N"
TMFFNAME SRVGRP=ADMIN3 SRVID=48 RESTART=Y
CLOPT="-A -- -F"
TMFFNAME SRVGRP=ADMIN4 SRVID=49 RESTART=Y
CLOPT="-A -- -F"

See Also

TMSYSEVT(5), userlog(3), UBBCONFIG(5), and the TP Framework chapter in the C++ Programming Reference.

TMIFRSVR

Synopsis

The Interface Repository server.

Syntax

TMIFRSVR SRVGRP="identifier" SRVID="number" RESTART=Y GRACE=0 CLOPT="[ servopts options ] -- [ -f repository_file_name ]"

Description

The TMIFRSVR server is a server provided by BEA for accessing the Interface Repository. The API is a subset of the CORBA-defined Interface Repository API. For a description of the Interface Repository API, see the C++ Programming Reference.

Parameter

[-f repository_file_name]
Interface Repository file name. This file must have been generated previously using the idl2ir command. If this parameter is not specified, the default repository file name repository.ifr located in the application directory (APPDIR) for the machine is used. If the repository file cannot be read, the server fails to boot.

Examples

*SERVERS

#This server uses the default repository TMIFRSVR
SRVGRP="IFRGRP" SRVID=1000 RESTART=Y GRACE=0

#This server uses a non-default repository TMIFRSVR
SRVGRP="IFRGRP" SRVID=1001 RESTART=Y GRACE=0
CLOPT="-- -f /nfs/repository.ifr"

See Also

idl2ir, UBBCONFIG(5), and servopts(5)

factory_finder.ini

Name

ASCII FactoryFinder domain configuration file

Description

factory_finder.ini is the FactoryFinder configuration file for domains. This file is parsed by the TMFFNAME service when it is started as a Master NameManager. The file contains information used by NameManagers to control the import and the export of object references for factory objects with other domains.

Definitions

A WLE system domain application is defined as the environment described in a single TUXCONFIG file. A WLE system application can communicate with another WLE system application or with another TP application via a domain gateway group. In "WLE system domain" terms, an application is the same as a TP domain.

A Remote Factory is a factory object that exists in a remote domain that is made available to the application through a WLE FactoryFinder.

A Local Factory is a factory object that exists in the local domain that is made available to remote domains through a WLE FactoryFinder.

File Format

The file is made up of two specification sections. Allowable section names are: DM_REMOTE_FACTORIES and DM_LOCAL_FACTORIES.

Examples

See Also

TMFFNAME, BEA TUXEDO /Domain Guide, C++ Programming Reference, and Java Programming Reference

Copyright © 1999 BEA Systems, Inc. All Rights Reserved.
Required browser version: Netscape Communicator version 4.0 or higher, or Microsoft Internet Explorer version 4.0 or higher.
Last update: July 05, 1999.