Smart Agent Features
Connecting Agents on Different Local Networks
Using Point-to-point Communications
Object Implementation Fault Tolerance
Smart Agent Features
VisiBroker's osagent is a dynamic, distributed directory service that provides facilities for both client applications and object implementations. When a client application invokes the _bind method on an object, the osagent locates the specified implementation and object so that a connection can be established between the client and the implementation. Object implementations register their objects with the osagent so that client applications can locate and use those objects. When an object or implementation is destroyed, the osagent removes them from its list of available objects. Agent Communication
An osagent may be started on any host. To locate an osagent, client applications and object implementations send a broadcast message, and the first osagent to respond will be used. Once an osagent has been located, a point-to-point UDP communication is established for registration and look-up requests. The UDP protocol is used because it consumes fewer network resources than a TCP connection. All registration and locate requests are dynamic, so there are no required configuration files or mappings to maintain. Agent-to-Agent Cooperation
When multiple instances of the osagent are started on different hosts, each osagent will recognize a subset of the objects available and communicate with other osagents to locate objects it cannot find. If one of the osagent processes should terminate unexpectedly, all implementations registered with that agent will be notified and they will automatically re-register with another available osagent. Cooperation with the OAD
The osagent maintains a list of all persistent object implementations that are registered with the Object Activation Daemon. When the ORB requests the osagent to locate an object that has been registered directly with the osagent, the address of the object is returned. If the requested object is registered with the OAD, the osagent will return the address of the OAD capable of activating the object and the ORB will contact that OAD.
Starting the osagent
At least one instance of the osagent should be running on your local network. The following example shows how to start the osagent. The verbose mode option provides informational and diagnostic messages. Local network refers to the part of the network within which broadcast message can be sent-machines in the same subnet
osagent -v
The following figure shows separate ORB Domains.
VisiBroker allows you to distinguish between two or more ORB domains on the same network by using a unique UDP port number for the osagents for each domain. The environment variable OSAGENT_PORT must be set on each host running an osagent, an oad, object implementations, or client applications assigned to that ORB domain.
Caution: Check with your system administrator to determine what port numbers are available for your use.
The following example shows the setting of the OSAGENT_PORT environment variable for a UNIX system running csh.
prompt> setenv OSAGENT_PORT 5678
prompt> osagent &
prompt> oad &
The following figure shows two osagent processes and their IP addresses, located on separate, connected local networks.
The following example shows the content of the agentaddr file for the osagent on network #1.
101.10.2.6With the appropriate agentaddr file, the client application on network #1 could locate and use object implementations on network #2. For more information on environment variables, see the VisiBroker for C++ Reference Guide.
Note: Even if a remote network has multiple osagents running, you need to list all of the osagents for that network in the agentaddr file.
prompt> server -ORBagentaddr 101.10.2.6 &...
or
prompt> client -ORBagentaddr 199.10.9.5
Caution: The rebind option, discussed in "Enabling Re-Binds" on page 3-8, must be enabled if the ORB is to be able re-connect the client with a replica object implementation.
rebind_succeeded method will be invoked by the ORB. The client can implement this method to bring the state of the replica up to date. Event handlers are described in Chapter 7.
Replicating Instantiated Objects
If the ORB objects that you wish to be fault tolerant are created by a server process instantiating the implementation's C++ class, you need only ensure that the server process is started on multiple hosts. Replicating Objects Registered with the OAD
If the ORB objects that you wish to be fault tolerant are registered with the oad, you must ensure that the oad is started on multiple hosts. Furthermore, you must ensure that the ORB objects are registered with each of the oad processes. Object Migration
Object migration is the process of terminating an object implementation on one host and then starting it on another host. Object migration can be used to move objects from overloaded hosts to hosts that have more resources or processing power. Object migration can also be used to keep objects available when a host has to be shutdown for hardware or software maintenance. Migrating Object that Maintain State
The migration of objects that maintain state is also possible, but it will not be transparent to a client application that has connected before the migration process begins. In these cases, the client application must register an event handler for the ORB object. When the connection to the original object is lost and the ORB re-connects the client to the object, the event handler's rebind_succeeded method will be invoked by the ORB. The client can implement this method to bring the state of the object up to date. Event handlers are described in Chapter 7.
Migrating Instantiated Objects
If the ORB objects that you wish to migrate were created by a server process instantiating the implementation's C++ class, you need only terminate the server process and start it on a new host. When the original instance is terminated, it will be un-registered with the osagent. When the new instance is started on the new host, it will register with the osagent. From that point on, client invocations will be routed to the object implementation on the new host. Migrating Objects Registered with the OAD
If the ORB objects that you wish to migrate are registered with the oad, you will need to ensure they are un-registered with the oad. Furthermore, you must ensure that the ORB objects are then registered with the oad on the new host. Here are the steps:
Advanced Networking Options
Although VisiBroker provides reasonable default settings for the network resources it uses, you may fine-tune these setting through parameters passed to the ORB_init method. The object implementation can set similar options through parameters passed to the BOA_init method. ORB_init Options
Figure 5-8 shows the definition of the ORB_init method and the arguments it accepts. The argc and argv parameters are passed in exactly the same format as arguments passed to your client's main routine. The argc parameter defines the number of arguments and argv is an array of char pointers to those arguments. ORB settings take the form of type-value pairs, enabling them to be distinguished from other arguments passed to your client application. In fact, the ORB_init method will ignore any arguments it does not recognize. The following section summarizes the ORB_init options.
The following example shows the
ORB_init method definition.
class CORBA {
...
static ORB_ptr ORB_init(int& argc, char *const *argv,
*orb_id = (char *)NULL);
...
};
In the preceding example, orb_id identifies the type of ORB. Currently "Internet ORB" is the only supported value.This section lists the ORB_init options. The type/value pair is given and then the purpose.
-ORBagentaddr ip_address
Specifies the IP address of the host running the osagent this client should use. If an osagent is not found at the specified address or if this option is not specified, broadcast messages will be used to locate an osagent. You can have a machine with many IP addresses. If you do have many IP addresses on a machine, specify a particular address on the command line for any program using the orb.
-ORBagentport port_number
Specifies the port number of the osagent. This option can be used if multiple ORB domains are in use, described in "ORB Domains" on page 5-4.
-ORBsendbufsize buffer_size
BOA_init Options
The following example shows the definition of the BOA_init method and the arguments it accepts. Like the ORB_init method, the argc and argv parameters passed to BOA_init are in exactly the same format as arguments passed to your object implementation's main routine. All but two of the BOA settings take the form of type-value pairs. The BOA_init method will ignore any arguments it does not recognize. The following section summarizes the BOA_init options. boa_identifier identifies the type of object-adaptor to be used.
class CORBA {
...
static BOA_ptr BOA_init(int& argc, char *const *argv,
const char *boa_identifier = "PMC_BOA");
...
};
BOA_init options are listed in the following section. The type/value pair is given first followed by the purpose.-OAipaddr ip_address
Specifies the IP address to be used for the Object Adaptor. Use this option if your machine has multiple network interfaces and the BOA is associated with just one address. If no option is specified, the host's default address is used.
-OAport port_number
Specifies the port number to be used by this process. If none is specified, an unused port will be selected.
-OAsendbufsize buffer_size
Specifies the size of the buffer used to send messages. If not specified, an appropriate value will be used.
-OArcvbufsize buffer_size
Specifies the size of the buffer used to receive messages. If not specified, an appropriate value will be used.
-OAnoshm
Disables the use of shared memory as a message transport.
-OAshm
Enables the use of shared memory as a message transport. This option is the default.