| |
|
|
|
1 Introduction
This section provides an overview of how you manage ObjectSwitch and the tools that you use to manage it. Later chapters of the book expand on these basic ideas.
Administration overview
ObjectSwitch is a powerful integration and mediation platform that performs most of its work transparently to applications running under it. However, there are still things that you need to configure, such as:
- the engines that make up an ObjectSwitch application
- some technical settings for ObjectSwitch itself
- ObjectSwitch adapters
These areas are summarized in the following paragraphs, and are discussed in greater detail throughout this book.
Engine execution and configuration
ObjectSwitch can automatically start your application engines, and restarts them when necessary. You can add and remove engines, control which ones are automatically started, and manually start and stop them.
Also, since different ObjectSwitch engines have different characteristics they are usually configured differently. Settings that you can change include timeouts, trace log settings, and other more technical tuning parameters.
ObjectSwitch configuration
There are a number of technical parameters that affect how ObjectSwitch performs overall. These settings control how memory is allocated, table sizes for hash lookups, timeouts and trace levels for ObjectSwitch's handling of engines.
Most of these parameters are set when ObjectSwitch is installed, and are effective only when an ObjectSwitch node is started for the first time. Some, however, may be useful for tuning overall system performance.
Adapter configuration
Some adapters, such as the database or CORBA adapters, require configuration for things such as:
- for database support, you configure how engines connect to database servers (this varies depending on the database vendor)
- for the CORBA adapter, you configure how the naming service and tracing levels are set up, as well as more technical timing and threading details
Some adapter parameters are configured separately for different engines that use them.
ObjectSwitch management tools
This section introduces the tools that you use to manage ObjectSwitch and its engines. Each tool is discussed fully in its own chapter of this book.
The Engine Control Center
The Engine Control Center lets you control engines on any ObjectSwitch node. You can use it to start, stop, add, and remove engines, and to modify registry settings associated with individual engines. You can also change these (or any other) registry values using the registry editor, but the Engine Control Center is a much better choice for engine-specific configuration. Chapter 3 describes the Engine Control Center.
The registry editor
ObjectSwitch comes with a graphical registry editor that you can use to edit any ObjectSwitch registry on the local physical node. Chapter 5 explains how to use the ObjectSwitch registry editor.
The system monitor
The system monitor lets you examine details of system operation. It interactively decodes shared memory on the local node to let you examine ObjectSwitch types and instances, gather state statistics, and other advanced features only touched on by this book. Chapter 4 describes the system monitor.
Command-line utilities
Most of the operations that you perform using graphical tools-such as the Engine Control Center or the registry editor-can also be performed from a UNIX command prompt. This lets you build configuration scripts that you can use:
- to set up many identical configurations
- to delete and re-install a prototype system multiple times with minor, controlled configuration changes
Chapter 6 describes the command-line utilities.
Distribution
A distributed ObjectSwitch system consists of multiple ObjectSwitch nodes, usually running on separate network nodes, which communicate among each other. The routing of events and object management between nodes is almost entirely transparent to ObjectSwitch applications, and is handled by a distribution engine running on each node.
There are a few properties to configure on each ObjectSwitch node to make distribution work. See "Distribution" on page 97 for more information about these properties.
Trace files
ObjectSwitch engines and the system coordinator can generate trace messages into a log file. These messages can be useful for debugging applications or diagnosing system performance. Each engine uses its own trace file, as does the system coordinator. You can use the Engine Control Center to set the filename, maximum size, and other characteristics of trace files.
An engine (or the system coordinator) only generates the types of trace messages that it is set to generate. You can use the Engine Control Center to control the trace level and trace filters used when generating a trace.
Trace level
There are four trace levels defined in ObjectSwitch. In decreasing order of severity, they are: fatal, warning, info, and debug. You can set the overall level of tracing using a registry key for the engine or coordinator.
Generating trace files can have a large effect on system performance. Normally you should only enable fatal trace messages.
Trace filters
In addition to the overall level of trace messages, you can also configure which parts of ObjectSwitch can generate each level of trace message. This is specified as four bitmasks, one per trace level, whose bits designate trace categories as defined in the following table. All bits not listed in the table are reserved.
Figure 1 shows an example in which fatal message tracing is allowed for system services and object services only, and all trace messages are allowed for distribution, by setting traceFatalFilter to 0x0105 and the other three filters to 0x0100.
For each individual engine, and for the System Coordinator, you can set:
For engine configuration you should only set the trace levels using the Engine Control Center (see Chapter 3). For the system coordinator, you will need to use the registry editor (see Chapter 5).
The entries in the trace file contain a date and time, a code indicating the category of the trace message, and the trace message itself. The following table lists the trace message categories.
More about the registry
The ObjectSwitch registry contains configuration information for ObjectSwitch and its engines. The registry stores keys and values. A key is a collection of subkeys and values. A subkey is a key contained by another key; keys are organized in a hierarchical structure.
Each key in the registry can contain one or more named values. These named values are the configuration variables for ObjectSwitch.
ObjectSwitch's configuration information is stored under a global key named DSEGlobalKey. The location of the global ObjectSwitch key is platform specific.
DSEGlobalKey is the root key in theObjectSwitch registry. By default, ObjectSwitch uses the registry named DSERegistry.sm in the current working directory. You can specify an alternate directory using the p argument when launching the system coordinator.
Modifying the registry
There are three ways to change entries in the ObjectSwitch registry. They are:
- setting engine and adapter properties in the Engine Control Center (see Chapter 3) - this is the "normal" way to change settings in the registry
- swregistry command line utility (see Chapter 6) - this utility is useful for scripting and for remote configuration from shells and scripts
- ObjectSwitch registry editor (see Chapter 5) - this is an low-level tool, and you should avoid using it
If there is no registry, ObjectSwitch creates one the first time it runs. You do not have to explicitly create the registry file.
If a value is needed from the registry and the value has not been defined, ObjectSwitch or the engine creates the appropriate variable and sets it to a default value. The default value for each variable is listed in Chapter 8.
 Kabira Technologies, Inc. http://www.kabira.com Voice: (415) 446 5000 Fax: (415) 446 5199 |
| |
|
|
|
