Object implementations can be registered using a command-line interface (oadutil). There is also a VisiBroker ORB interface to the OAD, described in
“IDL interface to the OAD”. In each case, the repository ID, object name, the activation policy, and the executable program representing the implementation must be specified.
Port 16000 is the default port, but it can be changed by setting the
listener.port property.
|
•
|
Use the oad.exe located in <install_dir>\bin\
|
The oad command accepts the following command line arguments:
The oadutil commands provide a way for you to manually register, unregister, and list the object implementations available on your VisiBroker system. The
oadutil commands are implemented in Java and use a command line interface. Each command is accessed by invoking the
oadutil command, passing the type of operation to be performed as the first argument.
An object activation daemon process (oad) must be started on at least one host in your network before you can use the
oadutil commands.
The oadutil command has the following syntax:
When registering or unregistering an object with the OAD, the oadutil commands allow you to specify either an object's IDL interface name or its repository id.
The #pragma ID and
#pragma prefix mechanisms can be used to override the default generation of repository ID's from interface names. If the
#pragma ID mechanism is used in user-defined IDL files to specify non-standard repository IDs, the conversion process outlined above will not work. In these cases, you must use
-r repository ID argument and specify the object's repository ID.
The oadutil list utility allows you to list all VisiBroker ORB object implementations registered with the OAD. The information for each object includes:
The oadutil list command returns all VisiBroker ORB object implementations registered with the OAD. Each OAD has its own Implementation Repository database where the registration information is stored.
The oadutil list command has the following syntax:
The oadutil list command accepts the following command line arguments:
The oadutil command can be used to register an object implementation from the command line or from within a script. The parameters are either the interface name and object name, the service name, or the POA name, and path name to the executable that starts the implementation. If the activation policy is not specified, the shared server policy will be used by default. You may write an implementation and start it manually during the development and testing phases. When your implementation is ready to be deployed, you can simply use
oadutil to register your implementation with the OAD.
|
•
|
An oad process must be started on at least one host in your network before you can use the oadutil reg command.
|
The oadutil reg command has the following syntax:
The oadutil reg command accepts the following command-line arguments:
Specifying vbroker.oad.locateAlways as
true ensures that the client can locate the POA; see
“OAD properties” for details of this property. The instance name is
/bank_agent_poa. The object has the
unshared policy, by which it will be terminated when the requesting client breaks its connection to the spawned server.
The following command will register with the OAD the VisiBroker program factory. It will be activated upon request for objects of repository ID
IDL:ehTest/Factory:1.0 (which corresponds to the interface name
ehTest::Factory). The instance name of the object to be activated is
ReentrantServer, and that name is also passed to the spawned executable as a command-line argument. This server has the unshared policy, by which it will be terminated when the requesting client breaks its connection to the spawned server.
The following command will register the VisiBroker Server class with the OAD. In this example, the specified class must activate an object of repository ID
IDL:Bank/AccountManager:1.0 (corresponding to the interface name IDL name
Bank::AccountManager) and instance name
CreditUnion. The server will be started with unshared policy, ensuring that it will terminate when the requesting client breaks its connection. The server is also passed with an environment variable
DEBUG=1 when it is first started by the client.
For example, let us assume that the OAD's IOR is located in the e:/adm dir (on Windows), and you want to run the bank_portable example that is included (in the
examples/basic/bank_portable directory) with with the product. To access this server without using the Smart Agent:
|
1
|
Start the OAD: the classpath visible to OAD must include the Server's classpath. The command is:
|
|
3
|
Generate the Server's IOR: when the server is started it will write out it's IOR into a file. Terminate the server once it is running, so that the launching of the server by the OAD can be demonstrated. The command is:
|
Your implementation can use ReferenceData to distinguish between multiple instances of the same object. The value of the reference data is chosen by the implementation at object creation time and remains constant during the lifetime of the object. The
ReferenceData typedef is portable across platforms and VisiBroker ORBs.
The CreationImplDef class contains the properties the OAD requires to activate a VisiBroker ORB object:
path_name,
activation_policy,
args, and
env. The following sample shows the
CreationImplDef struct.
The path_name property specifies the exact path name of the executable program that implements the object. The
activation_policy property represents the server's activation policy, discussed in
“Example of object creation and registration”. The
args and
env properties represent command line arguments and environment settings for the server.
The sample below shows the change_implementation() method which can be used to dynamically change an object's registration. You can use this method to change the object's activation policy, path name, arguments, and environment variables.
Although you can change an object's implementation name and object name with the change_implementation() method, you should exercise caution. Doing so will prevent client programs from locating the object with the old name.
Instead of using the oadutil reg command manually or in a script, VisiBroker allows client applications to use the
OAD::reg_implementation operation to register one or more objects with the activation daemon. Using this operation results in an object implementation being registered with the OAD and the
osagent. The OAD will store the information in the Implementation Repository, allowing the object implementation to be located and activated when a client attempts to bind to the object.
The CreationImplDef struct contains the properties the OAD requires. The properties are
repository_id,
object_name,
id,
path_name,
activation_policy,
args, and
env. Operations for setting and querying their values are also provided. These additional properties are used by the OAD to activate an VisiBroker ORB object.
The path_name property specifies the exact path name of the executable program that implements the object. The
activation_policy property represents the server's activation policy. The
args and
env properties represent optional arguments and environment settings to be passed to the server.
The following code sample shows how to use the CreationImplDef class and the
OAD.reg_implementation() method to register a server with the OAD. This mechanism may be used in a separate, administrative program, not necessarily in the object implementation itself. If used in the object implementation, these tasks must be performed prior to activating the object implementation.
The oadutil unreg command allows you to unregister one or more object implementations registered with the OAD. Once an object is unregistered, it can no longer be automatically activated by the OAD if a client requests the object. Only objects that have been previously registered via the
oadutil reg command may be unregistered with
oadutil unreg.
An oad process must be started on at least one host in your network before you can use the oadutil reg command.
The oadutil unreg command has the following syntax:
The options for the oadutil unreg command accepts the following command line arguments:
The oadutil unreg utility unregisters one or more VisiBroker ORB objects from these three locations:
The following is an example of how to use the oadutil unreg command. It unregisters the implementation of the
Bank::AccountManager named
MyBank from the local OAD.
You can use the oadutil tool to list the contents of a particular Implementation Repository. For each implementation in the repository the
oadutil tool lists all the object instance names, the path name of the executable program, the activation mode and the reference data. Any arguments or environment variables that are to be passed to the executable program are also listed.
module Activation
{
enum
state {
ACTIVE,
INACTIVE,
WAITING_FOR_ACTIVATION
};
struct
ObjectStatus {
long unique_id;
State activation_state;
Object objRef;
};
typedef sequence<ObjectStatus> ObjectStatusList;
struct
ImplementationStatus {
extension::CreationImplDef impl;
ObjectStatusList status;
};
typedef sequence<ImplementationStatus> ImplStatusList;
exception DuplicateEntry {};
exception InvalidPath {};
exception NotRegistered {};
exception FailedToExecute {};
exception NotResponding {};
exception IsActive {};
exception Busy {};
interface OAD {
Object
reg_implementation( in extension::CreationImplDef impl)
raises (DuplicateEntry, InvalidPath);
extension::CreationImplDef
get_implementation(
in CORBA::RepositoryId repId,
in string object_name)
raises ( NotRegistered);
void
change_implementation(in extension::CreationImplDef old_info,
in extension::CreationImplDef new_info)
raises (NotRegistered,InvalidPath,IsActive);
attribute boolean
destroy_on_unregister;
void
unreg_implementation(in CORBA::RepositoryId repId,
in string object_name)
raises ( NotRegistered );
void
unreg_interface(in CORBA::RepositoryId repId)
raises ( NotRegistered );
void
unregister_all();
ImplementationStatus
get_status(in CORBA::RepositoryId repId,
in string object_name)
raises ( NotRegistered);
ImplStatusList
get_status_interface(in CORBA::RepositoryId repId)
raises (NotRegistered);
ImplStatusList
get_status_all();
};