During the setup phase, an administrator is responsible for the planning, design, installation, security, and configuration of the BEA Tuxedo system. The following table describes the required and optional tasks during the setup phase.
Setup Task
Required
Optional
Collect information from designers, programmers, and business users of the application
X
Set up the hardware and software, and install the BEA Tuxedo system and the application (installation)
X
Set up the BEA Tuxedo system parameters that govern how the application uses components (configuration)
X
Configure transactions for domains, machines, groups, interfaces, services, and other required components (configuration)
X
Select and implement security methods for protecting the application and data
X
For CORBA environments, configure an Internet Inter-ORB Protocol (IIOP) Listener/Handler and modify the machine configuration
X
Set up distributed applications with routing tools: factory-based routing for CORBA environments and data-dependent routing for ATMI environments
X
Set up networked applications
X
Configure local and remote domains
X
Set up Workstation clients: add environment tables and a workstation listener, and modify the machine configuration
X
Create an application queue space and modify the configuration to support queued messages
X
Run-time Tasks
With your BEA Tuxedo system installed and your TUXCONFIG file loaded, you are ready to boot your application. When your application is launched, you must start monitoring its activities for problems—both actual and potential. The following table describes the required and optional tasks during the run-time phase.
Run-time Task
Required
Optional
Start up and shut down an application
X
Manage buffers
X
Administer the security of your application
X
Monitor the activities, problems, and performance of your application
X
For ATMI environments, manage transactions
X
For CORBA environments, manage interfaces
X
Manage networked applications
X
Manage remote Workstation clients
X
Subscribe to events
X
Use queued messaging
X
Identify and resolve problems as they occur (troubleshoot)
X
Reassign primary responsibility for your application from the MASTER machine to an alternate (BACKUP) machine (migration) when problems occur on the MASTER (migration)
X
Change system parameters and the selection of services to meet evolving needs (dynamic modification)
X
Refine your application to reflect additional components, such as new machines or servers (dynamic reconfiguration)
X
During run time, you may need to respond quickly to potential problems or evolving requirements of an application. To help you perform these functions, you have a choice of three tools: the BEA Tuxedo Administration Console, the command-line interface, and the AdminAPI. The following chart describes some of the circumstances in which your intervention may be needed.
To...
You May Want to...
Maximize performance
Adds load balancing or set priorities for interfaces and services.
Fix problems that may develop on the MASTER machine
Replaces it with a designated BACKUP machine.
Change processing and resource usage requirements
Adds machines, servers, clients, interfaces, services, and so on.
Differences Between the BEA Tuxedo ATMI and CORBA Environments
For the BEA Tuxedo CORBA environment, the BEA Tuxedo administration facilities support the administration of applications running within the context of the Object Request Broker (ORB) and the TP Framework.
The UBBCONFIG configuration file for BEA Tuxedo CORBA environments supports the configuration of client and server applications, as follows:
The RESOURCES section provides application-wide defaults for the sizing of bulletin board tables.
The MACHINES section allows the specification of processor-specific values for sizing of those tables.
The INTERFACES, section allows the specification of information about CORBA interfaces used by the application.
The ROUTING section provides support for a different type of routing criteria used with Tuxedo CORBA environments. Also, existing ROUTING sections that specify BEA Tuxedo ATMI data-dependent routing parameters continue to work without modification.
In the BEA Tuxedo ATMI environment, you configure workstation handlers and listeners for connections from client applications to server applications. From an administrative viewpoint, this task is similar in BEA Tuxedo CORBA environments.
However, the BEA Tuxedo CORBA environment uses a different communications protocol to connect remote and foreign clients to BEA Tuxedoserver applications. The protocol is the standard Internet Inter-ORB Protocol (IIOP). Instead of the BEA Tuxedo Workstation Handler (WSH) process and Workstation Listener (WSL) process, the CORBA environment calls its gateway processes the IIOP Handler (ISH) and the IIOP Listener (ISL). This results in a slight syntax difference, ISL instead of WSL, in the SERVERS section of each application's UBBCONFIG configuration file.
Overall, the administration tasks for the BEA Tuxedo CORBA and ATMI environments are similar. There are a few principal differences between the environments, however, as follows:
In both environments, you use a routing criteria to distribute processing to specific server groups. The routing mechanism in a BEA Tuxedo CORBA environment system is known as factory-based routing. It is fundamentally different than the BEA Tuxedo ATMI data-dependent routing mechanism.
In the BEA Tuxedo ATMI environment, you can examine any FML field used for a service invocation to determine the data-dependent routing criteria. In BEA Tuxedo CORBA environments, the system designer must personally communicate the routing criteria of CORBA interfaces. For BEA Tuxedo CORBA environments, there is no service request message data or associated buffer information available for routing. This occurs because CORBA routing is performed at the factory, not on a method invocation on the target CORBA object.
You cannot dynamically advertise CORBA interfaces at run time. However, you can suspend or reactivate CORBA interfaces.
No direct ACL control is provided for CORBA interfaces. No control over servants is provided at the administrative level. In the UBBCONFIG configuration file, the MANDATORY_ACL parameter to the SECURITY parameter is ignored.
The LDAP single security administration feature is not supported by the CORBA interface.
Note:
The Management Information Base (MIB) defines the set of classes through which the fundamental aspects of an application can be configured and managed. The MIB classes provide an administrative programming interface to the BEA Tuxedo CORBA and ATMI environments.
Planning the Design of Your Application
An administrator needs to know a customer's business requirements and how the software will be used. Once these needs are understood, administrators can work with their system designers and application developers to make sure that the application's configuration can support its requirements.
Answers to the following preliminary questions may help in planning the design of your application.
How many machines will be used? ____________________
Will client applications reside on machines that are remote from the server applications? _______________________
For ATMI, which services will your application offer? ____________________________________________________________________________________________________________________________
For CORBA, which interfaces will your client or server application use? __________________________________________________________________________________________________________________________
What resource managers (database) will the application use and where will they be located? __________________________________________________________________________________________________________________________
What "open" strings will the resource managers need? ____________________________________________________________________________________________________________________________
What setup information will be needed for an RDBMS? __________________________________________________________________________________________________________________________________________________________________________________________
Will transactions be distributed? ________________
Will the application use global transactions? ________________
What buffer types will be used? ____________________________________________________________
Will data be distributed across machines? _________________________________________________________
To which external domains will the application export services? From which external domains will the application import services? ____________________________________________________________________________________________________________________________________________________________________________________________
Will factory-based or data-dependent routing be used in your application? _________________________________________________________
What are the names of the CORBA interfaces or ATMI services? _________________________________________________________________________________________________________________________
In what order of priority should the interfaces or services be available? _________________________________________________________________________________________________________________________
What are the reliability requirements? Will redundant listener and handler ports be needed? Will replicated server applications be needed? ____________________________________________________________________________________________________________________________
For CORBA environments, will the domain need an Interface Repository (IR) database? If so, will the domain benefit from having IR replicas, and how many IR server applications should be defined? ____________________________________________________________________________________________________________________________
Are there any conversational services? What resource managers do they access? What buffer types do they use? _____________________________________________________________________________________________________________________
The BEA Tuxedo system gives you a choice of several methods for performing the same set of administrative tasks for either BEA Tuxedo ATMI or CORBA environments. Whether you are more comfortable using a graphical user interface or entering commands at a shell prompt, you will be able to find a comfortable method of doing your job as the administrator of a BEA Tuxedo application. The following figure illustrates the tools you can use to write the configuration file and administer your BEA Tuxedo application during run time.
Figure 1-1 Administration Tools
BEA Tuxedo Administration Console—a Web-based tool used to monitor an application, and to dynamically configure its operation.
BEA Tuxedo MIB Application Programming Interface—an interface to a set of procedures for accessing and modifying information in the MIBs.
Command-line utilities—a set of commands used to manage, activate, configure, and deactivate the application (that is, tmadmin(1), tmboot(1), tmconfig, wtmconfig(1), tmshutdown(1), respectively). For more information, refer to the BEA Tuxedo Command Reference.
If You Use This Tool...
You Must...
BEA Tuxedo Administration Console
Use a graphical user interface (GUI) to create and edit the TUXCONFIG file. Full descriptions of the GUI are available by accessing Help directly from the GUI.
BEA Tuxedo MIB Application Programming Interface
Write a program that modifies the TUXCONFIG file for you.
Command-line interface
Create and edit the UBBCONFIG file (a text version of TUXCONFIG) with a text editor.
Run tmloadcf to convert the UBBCONFIG file into a TUXCONFIG (binary) file.
(For specific details about the tmloadcf command options, see tmloadcf(1) in the BEA Tuxedo Command Reference.)
See Also
Management Operations Using the BEA Tuxedo Administration Console" in Introducing BEA Tuxedo ATMI
Managing Operations Using the MIB" in Introducing BEA Tuxedo ATMI
Managing Operations Using Command-Line Utilities" in Introducing BEA Tuxedo ATMI
