Tasks an Administrator Performs


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Setting Up a BEA Tuxedo Application \| Local Topics \| Previous Topic \| Next Topic \| Contents

An administrator's job can be viewed as two broadly defined tasks:

Setup tasks—all the tasks required to prepare your system before booting your application.
Run-time administration—any tasks performed on an application that has been booted.

Setup Tasks

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

See Also

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 Tuxedo server 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.

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.