Professional Documents
Culture Documents
1
Guide
3.0
Second Edition
Printed in the United States of America
Contents
1
Overview 1
Configuring and Managing a Distributed System 2
Voyager Servers 21
Configuring Voyager Servers 22
Defining System Properties 24
Defining CORBA-to-Java Mappings 25
Startup Using Voyager Directory Server 26
iii
Transaction Service 45
Monitoring Transaction Statistics 46
Viewing the Transaction Log 47
Viewing Active Transactions 49
Viewing Transaction Errors 50
Configuring Transactions 51
Communicating with the Server 52
JDBC Service 53
Configuring Datasource Properties 54
iv
Security Service 31
Securing the VMC and Directory Server 32
Securing the VMC Using a Custom Policy Implementation 34
Securing Voyager Servers Using BasicPolicy 34
Managing the Access Control List 39
EJB Service 57
Monitoring EJB Container Statistics 58
Configuring the EJB Container 60
Configuring an EJB Service with an LDAP Directory Service 67
Monitoring a Components Statistics 69
Configuring a Components General Properties 70
Viewing a Components Transactional Properties 72
Setting a Components Security Properties 73
Setting a Components Environment Properties 75
Viewing a Methods Transactional Properties 78
Setting a Methods Security Properties 79
Voyager Configuration
and Management
Overview
This manual details Voyagers configuration and management capabilities.
Several tools are used in deploying and maintaining a distributed system
using Voyager:
Chapter 1 Overview
Note: The content and structure of a Voyager Directory Server are described
in more detail in the Voyager ORB Developer Guide.
Given the above root directory object, Voyager will require the following URL to access
the directory. This URL specifies a directory server on a machine called dallas that is
listening on port 389. Consult your directory server documentation for instructions on
creating directory root objects.:
//dallas:389/VoyagerDirectory
JNDI Configuration
Voyager uses Java Naming and Directory Interface (JNDI) to access LDAP directory
servers. JNDI is a Java API that provides a standard interface for accessing different
naming and directory service implementations.
Setup
For each naming and directory service implementation, JNDI requires a specific service
provider. The service provider contains the Java classes necessary to access a specific
naming or directory implementation. To use Voyager with LDAP directory servers,
either an implementation-specific LDAP service provider or Suns LDAP service
provider is required.
Consult your directory server documentation for instructions regarding installation of
the LDAP service provider, or consult Suns web site to obtain Suns LDAP provider.
Once the service provider is installed, verify that the proper Java classes are accessible
from the classpath environment variable. Also, note the name of the initial context
factory class. The name of this class is provider-specific and will be needed later to
properly configure Voyager to use the LDAP directory server. For Sun, the class name
is com.sun.jndi.ldap.LdapCtxFactory.
System Properties
JNDI uses system properties to communicate certain information from the JNDI client
to the JNDI service provider. Voyager also uses system properties to configure Voyager
for use with LDAP directory implementations. These system properties are specified in
a Java properties file that is read by the Voyager Management Console on startup.
The name of the system property Voyager uses to determine the directory server
implementation is objectspace.directory.server.implementation. For LDAP directory servers,
the value of this property must be ldap. If this property is not set, Voyager Directory
Server will be used. If LDAP is specified, Voyager will, by default, delegate initial
context requests to Suns LDAP initial context factory. When using a different LDAP
service provider, set the objectspace.alternate.context.factory system property. The value of
this property must be the initial context factory of the alternate service provider. For
example:
java.naming.factory.initial=com.objectspace.voyager.jndi.spi.VoyagerContextFactory
objectspace.directory.server.implementation=ldap
objectspace.alternate.context.factory=com.company.LDAPInitialContextFactory
Property Description
This property is required when using
Voyager with naming or directory
implementations other than Voyager
Directory Server unless the provider URL
contains the LDAP protocol. See the
following section for more information
about the URL format. To use Voyager with
LDAP the value must be ldap.
Property Name
Property Description
objectspace.alternate.factory.initial
java.naming.factory.initial
java.naming.security.authentication
java.naming.security.principal
java.naming.security.credential
The specific LDAP application or the LDAP service provider may require other system
properties. Consult your directory server and service provider documentation for
information regarding environment properties.
LDAP Security
Currently Voyager only supports simple text string user names and passwords for
accessing LDAP directories.
a port to listen on
-j and a name to which to bind the directory
-f and the file to write items that are bound into the directory
The URL of this directory is now //dallas:8000/dir, where dallas is the hostname of the
system on which the directory was started.
The -p option requires a file containing system properties. The properties file should
contain all of the properties described in System Properties on page 6, as well as any
properties that are required by the LDAP server and the JNDI service provider being
used. An example properties file with settings for the above example follows:
java.naming.factory.initial=com.objectspace.voyager.jndi.spi.VoyagerContextFactory
java.naming.security.authentication=simple
java.naming.security.principal=directoryUser
java.naming.security.credential=userPassword
objectspace.directory.server.implementation=ldap
Note: The principal and credential property values should represent a user in the LDAP
directory with all access permission to the Voyager directory tree.
10
11
Tree View
12
Status Window
Note: Users of the VMC must be given all access permission to the Voyager directory
tree.
Starting VMC
Run the console utility to start the VMC. On startup, the VMC presents a dialog that
prompts you for a user name, password, and directory URL.
13
If the directory server is not secured, leave the name and password fields blank. If you
have the security service installed, see the "Security Service" chapter for more
information. In the URL field, specify the location of a running Voyager Directory
Server. For example, start a directory server on a machine called dallas with the
following command:
voyager //dallas:8000 -j dir -f 8000.db
14
Installing Services
Any time after the Voyager Directory Server is initialized, you may add new services to
the server profile template by selecting Install service from the File menu. This brings
up a file chooser dialog that is used to select either the jar file in which the desired
service was distributed or a serialized configuration object, which is a file with the
extension SER, distributed separately from the jar file. Information specific to that
service is then added to the Voyager Directory Servers server profile template.
15
The URL field is interpreted as relative to the root of the Voyager Directory Server. For
example, if you specify Servers/Test in the URL field, the server profile is at URL
//dallas:8000/dir/Servers/Test, where dallas is the machine name of the directory server, 8000
is its port, and dir is the name to which the directory is bound.
Server profile URLs may be specified arbitrarily. There is no predefined directory
structure for server profiles.
Creating Clusters
The Voyager Management Console makes it easy to create and administer a cluster of
servers that all share a set of configuration information.You can create logical clusters
to manage multiple servers. A logical cluster contains settings common to multiple
16
servers. Once a cluster has been created, any server profiles created under this cluster or
moved to this cluster will acquire the settings for the cluster. Some settings may be
modified only for the entire cluster, and others may be modified only within a server
profile.
Step 2. Enter the name for the cluster you are creating, and select the services to be
installed on that cluster.
Step 3.
Step 4. Configure the sharable information for that cluster by selecting the cluster icon
in the tree window.
Step 5. Configure the sharable service information for the installed services by
selecting the service nodes directly under the cluster node in the tree window.
17
Step 2. In the available cluster list, select the cluster to which you want to add the new
server. The list of selectable services is disabled when you select one of the available
clusters. Since each server placed in a cluster is virtually identical, the only services
installed for each server will be the services installed on that cluster.
18
Step 3. Click OK. The new server profile will appear as a child node of the cluster to
which it was added.
19
For more information on the administering either the individual servers or any of the
services installed on a cluster, see the sections on Voyager Servers and Voyager
Services: in the Voyager Administrator Guide.
Note: When a administering either a cluster or a server in a cluster, only certain
information may be modified. Shared information may only be modified on the
cluster node (or cluster services), and the server-specific information may only
be modified on the server node.
or
voyager 8000 j dir f dir.db
and a server is created with the name Server, the following command starts the server
with the configuration information stored in the directory server:
voyager d //dallas:8000/dir/Server
If that server profile is stored as a part of a cluster named Cluster, the startup command
becomes:
voyager d //dallas:8000/dir/Cluster/Server
If the server profile is moved back out of the cluster, the startup command returns to:
voyager d //dallas:8000/dir/Server
20
Voyager Servers
With the VMC, you can view and change the configuration options and
runtime setup of Voyager servers. Additionally, remote Voyager servers can
now discover configuration information from the directory during startup.
In this chapter, you will learn to:
21
22
Startup URL the port on which the Voyager server should listen for incoming
connections.
Startup application the class name and arguments for an application class to be
executed on startup. The main method of the class is called with the remaining Strings
passed in as arguments.
Maximum number of idle threads an integer that tells the ThreadManager an upper
bound for the size of the idle thread pool.
Voyager security manager a flag that toggles whether a VoyagerSecurityManager is
installed on startup.
Enable resource serving a flag that enables the HTTP resource server.
Enable resource loading a flag that enables Voyagers class loading mechanisms.
If this is disabled, dynamic proxy generation does not occur.
Resource URLs a list of addresses of HTTP servers that this Voyager server should
consult for resources.
Other resource loaders a list of class names used as alternate resource loaders
within this Voyager server.
Note: Changes do not take effect while a Voyager server associated with this profile is
running. Also, updating the configuration is not transactional, so there is no
locking against multiple VMCs editing the same configuration.
23
24
See the CORBA section of the Voyager ORB Developer Guide for more information.
25
This example associates the Voyager server with an entry called Servers/Test in the
Voyager Directory Server running at //dallas:8000 whose directory is bound to the name
dir.
During startup, Voyager contacts the directory server and retrieves its server
configuration object, which contains all of the runtime configuration information for the
Voyager server itself. Voyager also iterates through the other entries in the specified
profile. It retrieves any configuration objects for services. When each service is started,
it is responsible for installing a Management Agent back into the server profile in the
Voyager Directory Server if necessary.
To associate a Voyager server with a server profile created using the Voyager
Management Console (VMC) that is stored in a Voyager Directory Server, run the
Voyager utility with the -d option. For example, if a server profile named servers/test was
created in a Voyager Directory Server running on a machine named dallas that is
listening on port 8000 use the following command:
voyager d //dallas:8000/servers/test
If the Voyager Directory server is secured using BasicPolicy, then BasicPolicy must also be
used to secure the Voyager server being configured. In addition, a user name and
password must be specified to allow the Voyager server to connect to the Voyager
Directory Server. To specify the security policy implementation and the user name and
password, use the voyager utility -p option. The -p option loads system properties from a
file. The file name is specified on the command line. For example:
voyager d //dallas:8000/servers/test p properties.file
In the above example properties.file is the file name of a file containing the information
necessary to allow the Voyager server to access the Voyager Directory Server. An
example file follows:
26
objectspace.security.policy.1=com.objectspace.security.policy.BasicPolicy,props/security.server.properties
java.naming.security.principal=directoryAdmin
java.naming.security.credentials=directoryAdmin
This example assumes that there is already a file called 8000.db that is a valid Voyager
Directory Server database and contains a profile called Servers/Test.
Note: In this case only, when specifying the profile URL after the -d option, do not
include the machine name or IP address for the local host.
27
28
Voyager Services
Security Service
With the features of Voyager Security, you can secure both Voyager servers
and the VMC.
In this chapter, you will learn to:
Note: The security service is only available in the Voyager Security and
Voyager Application Server products.
31
Step 2.
Step 3. Install the security service. Select Install Service from the file menu of the
VMC, then choose the Security Service's jar file or serialized configuration object from
the resulting file dialog.
Step 4. Create or import a system user using the Voyager Management Console. Create
a user with the tools described in the "Managing the Access Control List" section on page
39. The user represents the system when it accesses the directory server. This user must
be granted directory permission. Adding permissions to users is described in the
"Managing the Access Control List" section. Optionally other users could be added at this
step, but the system user is required.
Step 5. Restart the Voyager Directory Server in a secured state. Stop the directory
server started in step 1. Restart it using the -p option. For example:
voyager 8000 -j dir -f 8000.db -p server.properties
The file specified with the -p option should contain the following text:
objectspace.security.policy.1=com.objectspace.security.policy.BasicPolicy, filename
filename is the name of the file with the security properties. For example:
objectspace.security.policy.1=com.objectspace.security.policy.BasicPolicy,security.properties
32
directory.url
directory.username
Leave blank.
directory.password
Leave blank.
security.owner.username
Leave blank.
security.owner.password
Leave blank.
security.system.username
security.system.password
Step 6. Restart the VMC in a secured state. Stop the management console started in
step 2. Restart a secured management console. To start a secured management console,
type console at the command line followed by a file name. For example:
console client.properties
After this setup process is completed, the VMC requires a user name and password to
log in. For users to login to the console, they must have directory permission. Any
Voyager server started using the voyager utility with the -d option will also require the
user name and password of a user with directory permission. To specify the user name
and password use the -p option of the voyager utility. The -p option requires a properties
file. The properties file should include the following:
Voyager Administrator Guide
33
objectspace.config.password=username
objectspace.config.username=password
where username is the user name of the user that exists in the ACL with directory
permission, and password is the password of this user.
34
loaded by the BasicPolicy during startup. BasicPolicy on a running server will be notified
by the VMC when changes are made to the ACL.
Note: BasicPolicy on a running server will not be notified of ACL changes if the VMC is
run in an unsecure state. The following section explains how to secure the VMC and
the Voyager Directory Server using BasicPolicy.
To secure a Voyager server, specify the security policy implementation during startup.
Voyager obtains the configuration information from a properties file. Use the -p option
when starting a Voyager server to specify the properties file. For example:
voyager -p server.properties 8000
To use BasicPolicy, the file specified with the -p option must contain the following text:
objectspace.security.policy.1=com.objectspace.security.policy.BasicPolicy, filename
filename is the name of the file with the security properties. For example:
objectspace.security.policy.1=com.objectspace.security.policy.BasicPolicy,security.properties
Alternatively, you can specify that BasicPolicy be the security policy implementation
using the VMC Server Properties tab that defines system properties for a server profile.
Use objectspace.security.policy.1 as the property key and
com.objectspace.security.policy.BasicPolicy, filename as the property value where filename is the
name of the file with the security properties as above.
The file can contain the following entries:
policy.server
directory.url
directory.username
directory.password
35
security.owner.username
security.owner.password
security.system.usernam
e
security.system.password
Clients that use servers secured by the BasicPolicy must also specify BasicPolicy as their
security policy. The properties file is optional for the client and should only be used to
specify a security owner if needed. If a properties file is used by a client, policy.server
should equal false.
Note: Passwords are stored in clear text, so it is critical that you protect the properties
file from unauthorized access on the native platform.
36
Property Key
Property Value
objectspace.directory.server.implementation
ldap
java.naming.factory.initial
com.objectspace.voyager.jndi.spi.VoyagerContext
Factory
java.naming.security.authentication
simple
Note: Voyager servers using BasicPolicy which read the ACL from an LDAP directory
server must be restarted for any changes to the ACL to take effect.
The following is an example of a Basic Policy properties file with the above properties
added. In this example, Suns LDAP service provider is used:
// if true, all subsequent fields must be filled in
policy.server=true
directory.url=//localhost:7000/ACLDirectory
directory.username=directoryAdmin
directory.password=directoryAdmin
security.owner.username=securityOwner
security.owner.password=securityOwner
security.system.username=systemPrincipal
security.system.password=systemPrincipal
objectspace.directory.server.implementation=ldap
java.naming.factory.initial=com.objectspace.voyager.spi.jndi.VoyagerContextFactory
java.naming.security.authentication=simple
Basic Policy uses the directory.username and the directory.password properties as the user
name and password to access the directory server. This user must have read and write
access to the Voyager directory tree. Also the directory.url entry is the URL used by the
Basic Policy to access the directory. In this example, //localhost:7000 is the URL to the
directory server, and the Voyager directory tree name is ACLDirectory.
To use an initial ContextFactory other than Suns, use the objectspace.alternate.factory.initial
property.
37
ACL Installer
Installer is a command line tool used to load a Basic Policy ACL into the directory server.
To use installer with an LDAP directory server, pass a properties file name as the second
parameter when invoking installer. For example:
aclinst //dallas:389/ACL simple.acl ldap.props
The above example specifies a directory server on a machine called dallas that is
listening on port 389. The Voyager directory tree name is ACL.
The properties file must contain the following properties:
Property Key
Property Value
objectspace.directory.server.implementation
ldap
java.naming.factory.initial
com.objectspace.voyager.jndi.spi.VoyagerContext
Factory
java.naming.security.authentication
simple
java.naming.security.principal
java.naming.security.credential
The example properties file uses Suns service provider. The user represented by the
java.naming.security.principal and java.naming.security.credential entries must have read and
write access to the Voyager directory tree. To use an initial ContextFactory other than
Suns, use the objectspace.alternate.factory.initial property.
38
39
Use the buttons below the Users list to add users, remove users, and update user
passwords.
Adding a User
Adding a user creates an entry in the ACL with the user name and password of the user.
Two users are equal when they have the same user name and password. Therefore a user
can have multiple passwords, and each ACL entry associated with that user name and
password combination might have different access permissions.
To add a user, press the Add button. The following dialog appears requesting the user
data. Each field is required.
40
If the Password and the Confirm Password fields are not equal, an error occurs. An error
also occurs when the given user name and password already exist.
Removing a User
Removing a user removes the ACL entry for that user from the ACL. To remove a user,
select the user name from the list, and press the Remove button. A confirmation dialog
is posted to allow the action to be canceled.
Adding permissions
Adding a permission adds it to the ACL entry of the selected user. To add a permission
to a user principal, select the user from the Users list, and then press the Add button
under the Permissions list. The following dialog appears, requesting the required data.
41
The Permission field is a drop-down list of available access permissions. The Target and
Actions fields are enabled when the chosen permission requires a target or an action.
The target refers to the entity requiring permission to be accessed. Actions refers to the
type of access allowed by the target. For example, a target might be access to a
particular file, and the actions might be read/write/execute. Choose the desired
permission and enter the required data for that permission, and then press the OK button.
Removing permissions
Removing a permission from a user removes the selected permission from the ACL
entry for that user. To remove a permission from a user, select the permission from the
permissions list, and press the Remove button. A confirmation dialog is posted to allow
the action to be canceled.
42
To add the new permission type, the fully qualified class name of the custom permission
is required.
Permission types may also be removed from the Permission Types list. Permission types
that are removed are no longer available to add to a user, but existing instances of a
removed permission type will not be removed from the user principal. Use the buttons
below the Permission Types list to add and remove Permission types.
43
Importing Permissions
The Import button allows mass addition of user principals and their permissions. The
import function parses a file with the following format:
grant username "some user" password "users password"
{
permission com.objectspace.some.Permission "target", "actions";
permission com.objectspace.security.policy.SecurityPermission;
};
grant username "another user" password "users password"
{
permission com.objectspace.some.Permission "target", "actions";
permission com.objectspace.security.policy.SecurityPermission;
permission com.objectspace.security.policy.DirectoryPermission;
};
The import merges the users from the imported file into the existing ACL. If the import
file contains a user and password that already exist in the ACL, any new permission
from the file is added to the existing user. If a new permission type is encountered, it is
added to the Permission Types list.
To import an ACL file, press the Import button, and then select the file name from the
file dialog.
44
Transaction Service
45
46
47
48
49
50
Configuring Transactions
The configuration panel allows you to configure transactions.
Log Address: The URL where the transaction service will locate the logging service.
If the transaction service does not already exist at this location, Voyager will create
the transaction service at this URL. This optional feature can be useful if multiple
nodes wish to use a single logging service.
Log Factory: The name of the class implementing the ILogFactory interface that will
be created locally (if no Log Address is specified) or remotely (if specified and not
already existing). Do not change this value.
Service Address: The URL referring to a transaction factory that will create
Coordinators and Recovery Coordinators for this node.
Note: This option is not recommended as all transaction effort will result in a
significant increase in lag time due to network access.
51
52
JDBC Service
If a Voyager server is configured with the JDBC service, it has a subfolder
named JDBC in its server profile. The panels in this folder are used to
configure JDBC datasources for a server. See the Voyager Setup Guide for
information on how to install the JDBC Service.
In this chapter, you will learn to:
Note: The JDBC service is only available in the Voyager Transactions and
Voyager Application Server products.
53
Name
JNDI name to which the datasource is bound. This name should start with jdbc/ to
remain compliant to the JDBC specification. For example, if a database of employee
information is being configured as a datasource, it should be named jdbc/EmployeeDb.
Driver
Classname of the JDBC driver. The classname must be fully qualified and must be
available on the server.
URL
URL of the database. The URL identifies the actual database instance to which the
driver connects.
Login ID
Database user on whose behalf connections are made.
Login PW
Password to use with the database user identity
Initial Capacity
Number of database connections that should be created upon startup. The pool grows
as needed.
Growth Rate
Sets the rate at which database connections are created. If the pool is empty and a
connection is requested by the application, the datasource creates the number of
connections specified in this field.
54
Max Capacity
Sets the maximum size of the connection pool.
Note: This parameter is not the maximum number of connections; it is the maximum
number of free-pooled connections. If the pool is full, and a connection is being
returned to the pool, the connection is not added, it is closed.
55
56
EJB Service
If a Voyager server is configured with the EJB service, it has a subfolder
named EJB in its server profile. Two panels are associated with the EJB
subfolder: Statistics and Configuration. Three actions are associated with the
EJB subfolder: Start Container, Stop Container, and Insert Jar.
The panels and subfolders in this folder deploy new components, configure
existing components, configure the EJB container, and monitor component
and container statistics. See the Voyager Setup Guide for information on how
to install the EJB Service.
In this chapter, you will learn to:
57
Note: The EJB service is only available in the Voyager Application Server
product.
58
Created This number represents component instances created in the system. The
number of active, removed, terminated and timed out component instances must add
up to this number.
Active This number represents the number of component instances currently in use
by clients.
Removed This number represents the number of component instances removed
normally. A component instance is removed normally when the client removed it
through the remove method.
Terminated This number represents the number of component instances removed by
the system. A component instance is terminated when an unhandled RuntimeException
is thrown during the execution of one of its methods. Component instances are also
terminated when an administrator stops the EJB service, disables a particular
component, or updates or deletes a jar file while the component instance is in use.
Timed Out This number represents the number of component instances removed
because they timed out. A component instance times out when it has been in existence
for at least as long as the time-out set for the component. A component instance
typically times out when its client dies unexpectedly.
If the server is not running, the value of each statistic is empty. Any numeric value,
including zero, indicates that the server is up and communicating with the console. By
default, statistics automatically refresh every 15 seconds. To turn off the auto-refresh
feature, click on the check box. To change the refresh rate, enter it in the refresh rate
field, and tab out of the field. To manually refresh the statistics at any time, click on the
Refresh button.
59
60
When the home directory is set to be the configuration directory server, all clients will
be performing their home lookup on the directory server that the management console
uses to store server configuration information. this configuration is not recommended.
It is generally preferred to keep the clients and the administration separate, thereby
reducing the risk of security violations, data contamination, and so forth. To deploy
with this configuration, put the hostname and port of the configuration directory in the
Home Directory URL field.
In the server configuration, a server binds its home objects in memory, and clients
connect directly to the server to perform home lookup. This is the easiest to configure,
but does not scale well. It is considered a reasonably lightweight configuration. To
deploy in this configuration, put the hostname and port of the server whose profile is
being edited in the Home Directory URL field.
When a second directory server runs, the directory server is dedicated to the task of
providing clients with home lookup. A directory server is started, and multiple servers
are configured to bind their homes into this directory. This configuration removes the
burden of home lookup from each server but allows for a centralized directory lookup.
To deploy with this configuration, put the hostname and port of a directory server in
the Home Directory URL field. Start this directory before starting the servers.
For all configurations, set the Logical Server Name to some value. This value does not
have to be the same name as the server profile name. They are usually different. The
logical server name provides an abstraction layer between the physical server and
clients. This name can be any string, as long as it is unique to the server.
Note: Future versions of Voyager will allow multiple servers to share a logical server
name. In this configuration, a logical server name includes a cluster of physical
servers to support load-balancing and fault-tolerance.
Changes to the directory URL and server name do not affect a running server. Restart
the server to take advantage of the modified settings.
The logical server name becomes a JNDI context into which all home objects for this
server are bound. Clients can therefore connect to the URL created by the concatenation
of the home directory URL and logical server name. For example, assume the directory
is on the local host, the logical server name is FooServer, and the bean home name is
FooHome. The following code allows a client to look up the home object:
Hashtable env = new Hashtable();
env.put( Context.PROVIDER_URL, "//localhost:8000/FooServer" );
InitialContext ctx = new InitialContext( env );
IFooHome home = (IFooHome) ctx.lookup( "FooHome" );
Note: If the Voyager server and the Directory Server are running in the same VM, the
logical server name should not be set to anything.
61
62
System Identity
The container uses the System Identity field when a components security run-as mode
is set to System. The field allows a component to invoke another component as the
system. The field is also used to connect to the home directory and should have
directory permissions when the directory is secured.
Administrators can stop all usage of EJB components by clicking on the Stop button (for
example, to perform server maintenance). Stopping the EJB container removes all active
component instances, and component instances are identified as Terminated in the
Statistics panel. If the component instance is associated with a container-managed or
bean-managed transaction, the transaction is rolled back. If the component instance is
associated with a client-managed transaction, the transaction is marked for rollback.
Any component instances in the process of fulfilling a client request completes before
being removed. To restart the EJB Container, click on the Start button.
New components are deployed into a system from the standard EJB jar file format using
the Insert Jar button. The server does not need to be running. The components are not
enabled until the administrator explicitly enables each component, allowing the
63
A deployed jar file must be updated as new versions of its components are released. To
update a deployed jar file, click on the jar node in the tree and then click on the Update
button. Select the new version of the jar file from the file system. If any of the classes in
64
the jar file changed, stop the server while the jar file is being updated. When updating jar
files, if a component was already deployed and is being updated by the jar file, the
following properties are not updated, because the deployment information is typically
more appropriate.
The following properties use the values from the new jar file:
Bean Class
Home Interface
Remote Interface
Bean Type
All Transaction Properties
Environment properties merge, and new properties from the new jar file are added.
Properties removed from the new jar file are removed. Properties that exist in both the
deployed jar and the new jar file use the deployed jar files values, because since the
appropriate values are better known at deployment time, they are kept.
The Update Jar action can be performed whether or not the server is running. However,
changes are not reflected in the server until it is restarted.
To delete a deployed jar file, click on the jar node in the directory tree, and then click on
the Delete button. Deleting a jar removes all of its components from the configuration
directory. It also removes all of its components from the server when the server is
currently running. If any of the components have active instances, these instances are
removed and identified as Terminated in the statistics panel. If a component instance is
associated with a container-managed or bean-managed transaction, the transaction is
rolled back. If a component instance is associated with a client-managed transaction, the
transaction will be marked for roll back. Any component instances that are in the
process of fulfilling a client request complete the request before being removed.
The component nodes allow administrators to configure those aspects of a component
that are not design decisions. Configuration changes do not immediately take affect, you
must click on the Apply button first to apply all changes to the deployed component. To
65
cancel your changes, click on the Cancel button. The statistics refresh rate takes effect
immediately, and does not require pressing the Apply button.
66
To specify that bean home objects should be stored in an LDAP directory server, enable
the Replace System Properties check-box, and enter the necessary system properties.
The following table summarizes the properties that must be specified.
67
Key
Value
objectspace.directory.server.implementation
ldap
java.naming.factory.initial
com.objectspace.voyager.jndi.spi.VoyagerContext
Factory
java.naming.security.authentication
simple
java.naming.security.principal
java.naming.security.credential
Other properties may be required depending on the JNDI service provider and the
LDAP directory server implementation.
To use an initial ContextFactory other than Suns, use the objectspace.alternate.factory.initial
property.
68
69
70
Home Name
Clients can create a component instance by placing its home object in a well-known
location in JNDI. The bean home name specifies the JNDI location where the home
object should be put. Clients must know this name to create an instance.
Bean Type
The bean type is determined during design. This information is not editable by
administrators and is displayed for informational purposes only.
71
72
73
Allowed Identities
The users in the Allowed Identities list are the only users that can access the specified
component or method. The one exception to this rule is that if no users are in the list,
everyone has access to the component. To insert a new allowed identity, click on the
Insert button, and select the correct user. To remove an allowed identity, select it in the
list, and click on the Remove button.
When calling other components, choose one of three options to determine the identity to
use:
74
Client Identity If Client Identity is chosen, the identity associated with the current
client is used when interacting with other components.
System Identity If System Identity is chosen, the system identity is used when
interacting with other components. The system identity is a special identity specified
by Voyager that has system privileges.
Specified Identity If Specified Identity is chosen, the administrator-specified user
identity is used when interacting with other components. By default, this is None,
which means that no identity is used. To select a specified identity, click on the
Specified Identity radio button to select the mode, click on the Browse button, and
select the correct user identity. Specified Identity is the default value for interacting
with other components, with no specified identity. As a result, no identity is
propagated to called components by default.
75
To insert a new environment property, click on the Add button and insert a new row. To
change the property name or value, click on the cell, and type the new name or value. To
remove a property, click on any cell in the row, and click on the Remove button.
Administrators can stop all usage of an EJB component by clicking on the Disable
button (for example, to perform maintenance). Disabling a component prevents any new
client connections and removes all active component instances which are identified as
Terminated in the statistics panel. If the component instance is associated with a
container-managed or bean-managed transaction, the transaction is rolled back. If the
component instance is associated with a client-managed transaction, the transaction is
marked for roll back. Any component instances that are in the process of fulfilling a
client request complete the request before removal. To restart the component, click on
the Enable button.
76
77
78
79
80