Previous | Naming Service Configuration | Next |
The Naming Service entry for the Singleton.
The IOR URL property specifies the location of an Interoperable Object Reference (IOR) for the Service, using the Universal Resource Locator (URL) format. This information is used when a client attempts to resolve a reference to the Service. Currently only http and file URLs are supported, for example:
file:/usr/users/openfusion/servers/NameService.ior
http://www.prismtech.com/openfusion/servers/NameService.ior
The IOR File Name option specifies the name and location of the IOR file for the Singleton. If this property is not set, the IOR file name will be:
<INSTALL>/domains/<domain>/<node>/<service>/<singleton>/<singleton>.ior
where <INSTALL> is the OpenFusion installation path. See The Object Hierarchy for details of the domains directory structure.
The ORB Service resolution name used to resolve calls to the Singleton
The name of the Naming Service which will be used to resolve the Singleton object.
The Naming Service uses Sun Microsystems' JNDI (Java Naming and Directory Interface) LDAP provider. This allows the Naming Service to be stored in a standard LDAP server. Caching is not supported under the LDAP persistence option.
The administrator of the LDAP server may want each user to have their own login name and password. This property specifies the user name. The user name should be in the fully qualified LDAP format, for example:
uid=RNCross,ou=People,o=prismtechnologies.com
The administrator of the LDAP server may want each user to have their own login name and password. This property specifies the password.
The URL specifies the location within the LDAP server where the Naming Service should store its persistent data. The data will not appear in the traditional hierarchical format due to limitations of the LDAP storage mechanism.
ldap://excalibur.prismtechnologies.com:2809/ou=OpenFusion Naming Service,o=prismtechnologies.com
Output hexadecimal dump of the incoming and outgoing LDAP ASN.1 BER packets from the LDAP server.
LDAP Authentication Mechanism. The security method may be:
The administrator must enable all privileges upon the target location in the LDAP hierarchy when anonymous bind is selected. The LDAP v3 protocol uses the SASL to support pluggable authentication. This means that the LDAP client and server can be configured to negotiate and use possibly non-standard and/or customized mechanisms for authentication, depending on the level of protection desired by the client and the server. The LDAP v2 protocol does not support the SASL.
A list of mechanisms should be entered in the configuration tool when the SASL option is chosen, for example:
DIGEST-MD5 CRAM-MD5
This specifies that DIGEST-MD5 authentication is to be used, or that CRAM-MD5 authentication is to be used when the SASL mechanism is unavailable. An AuthenticationNotSupportedException will be thrown when neither is available.
The Naming Service provides two extra persistence options and a read cache for the caching of naming contexts.
The different kinds of caching available to the Naming Service are:
The interval, in seconds, between read cache flush operations. A least-recently-used algorithm is employed to reduce the size of the cache to the level of the Read Cache Minimum Size.
The default value is 0 (zero), which indicates no timed cache flush will be performed.
The maximum number of objects that the read cache will be allowed to hold. A value of zero means that there is no read cache. When the cache reaches the read limit size, a least-recently-used algorithm is employed to reduce the size of the cache to the level of the Read Cache Minimum Size.
The Read Cache Maximum Size must be set greater than zero if a write cache is required, as it is not possible to have a write cache without a read cache.
The minumum number of objects which will be left in the cache when it is cleared. The default value is 0 (zero).
The write interval option refers to the delay (in seconds) between saving object state changes within a server, and writing this information to persistent store. This option is a performance optimization feature as it can be used to prevent the service making a lot of small updates to the persistent store.
A value of zero indicates no delay. Changes are written immediately to the persistent store if both the Write Cache Write Interval and Write Cache Batch Size are set to zero.
The default value for this property is zero. Increasing the write interval value may improve performance when the data held by a service is changing rapidly.
The Write Batch Size option specifies the maximum number of updates that will be buffered before the data is written to persistent storage. Just as for the write interval option, the write batch size option is also a performance optimization feature.
A value of zero indicates that the updates are not buffered but are written immediately to the datastore. Increasing this property value may improve performance when the data held by a service is changing rapidly.
The Read Cache Maximum Size must be set greater than zero if a write cache is required, as it is not possible to have a write cache without a read cache.
The effect of setting both the Write Interval and Write Batch Size to values greater than zero is that of batched timed writes.
This property sets the persistent storage type. The type can be:
If Default is selected, the data store will default to the location of the service data (using JDBC). See Storage Type for details.
The interfaces for setting the instrumentation properties are given below. For information on managing instrumentation, see Instrumentation.
The number of resolve operations since the Service started or was last reset.
The number of rebind contexts in service since the Service started or was last reset.
The number of context binds in service since the Service started or was last reset.
The number of unbinds in service since the Service started or was last reset.
The number of rebinds in service since the Service started or was last reset.
The number of binds in service since the Service started or was last reset.
The internal ContextFactory cache can be purged to prevent the possibility of memory leaks. This property specifies the interval, in seconds, between ContextFactory cache flush operations. A value of zero indicates that no timed cache flush will take place.
JNDI ContextFactory Cache Flush Interval is used in conjunction with the JNDI ContextFactory Cache Maximum Size and JNDI ContextFactory Cache Minimum Size properties to determine the purging behaviour.
The maximum number of contexts allowed in the ContextFactory cache. When the cache exceeds this size, contexts are purged according to a least-recently-used algorithm
The size that the ContextFactory cache will be reduced to following a cache flush. For example, if this property is set to 10 then all but 10 contexts will be purged during a flush operation.
The location of the jndi.properties file. If this is left blank, the jndi.properties file will not be created.
The jndi.properties file is useful for JNDI client applications that need to connect to the Naming Service hierarchy.
The OpenFusion JMS Manager requires a valid jndi.properties file. See JMS Manager for details.
When more than one Naming Service is used, each one must be configured to use a different jndi.properties file.
The location that the of.jndi.properties file will be written to. If this is left blank, the file will not be created.
The of.jndi.properties file can be used by JBoss (and other application servers) to access the OpenFusion JNDI properties. As an alternative to using this file, properties could be hard coded or passed to an application as command-line parameters.
This option allows the root ID used by the JNDI hierarchy to be manually configured. This is useful when used in conjunction with the Server Persistent ID (SID) property (see Server Persistent ID) as these are then known values that may be passed to JNDI client programs. These clients can then access the Naming Service persistent data.
See the OpenFusion Naming Service Guide for more details of using JNDI
This allows load balancing to be performed by the Naming Service.
This allows the Naming Service to browse a JNDI hierarchy even when non-CORBA objects (e.g. java.lang.String) have been stored. The Naming Service will log and ignore any non-CORBA objects it encounters when this option is disabled.
Invalid object references (that is, those object references which are not active and not persistent) are removed from a naming context when the list operation is performed on the context and Purge on List is selected.
Object purging is discussed in detail in the OpenFusion Naming Service Guide.
Invalid object references (that is, those object references which are not active and not persistent) are removed when contexts are first accessed after a server has been restarted and Purge on Load is selected.
Object purging is discussed in detail in the OpenFusion Naming Service Guide.
This should be a publicly instantiable Java class that implements the com.prismt.openfusion.plugin.Purgable interface. This interface has one operation:
public boolean isPurgable (org.omg.CORBA.Object obj)
This class is used to determine whether or not to purge objects from the Naming Service. Typically, a client will code this operation to determine whether their object is persistent or transient and hence may be purged. This service will also check the active/inactive state. The ObjectAdapter.isTransient method is the default used when a class is not specified. This will successfully determine the persistent state for objects created using the OpenFusion framework, but it will not work for foreign objects.
Purging is the deletion of invalid object references and purgable objects from a service. Object references are regarded as invalid when they are not active and not persistent. The OpenFusion Naming Service can most easily determine whether an object is purgable if the com.prismt.openfusion.plugin.Purgable interface is implemented. See the OpenFusion Naming Service Guide for further details.
This property should be set to true (checked) if this is the master naming service for a system. There can be only one master naming service.
Previous | Naming Service Configuration | Next |