The Stibium Naming and Directory Server

Yes: it stores data and is, therefore, a database. However, it is not a relational database. Stibium uses hierarchical storage structures, whereas a relational database uses tabular data structures. In this respect, Stibium is more like a standard computer file system. Relational databases can, of course, be made to store hierarchical data, by the use of suitable normalisation and table joins, but it is not their intrinsic mode of storage.

It is also possible to configure a storage context in Stibium to be transient, which means that we do not want the contents of the context to survive server restarts or resets. This imposes a (indeterminate) time limit on the storage of data, which may run counter to some people's concept of what constitutes a database.

No. LDAP servers support the Lightweight Directory Access Protocol, which Stibium does not.

Stibium does support some LDAP-like search operations. These operations can be performed, either by using the DirContext search functions, or Stibium's xpath selector function, which is part of the RCRT.Stibium.naming.ContextExtension interface.

There are several ways of doing this, depending on the situation:

• The Stibium Web Front End.

  The simplest way is to log on to the Stibium web front end and take a look. However, what you see when you do this will depend on your access rights. You will not be able to see data for which you do not have read permission.

• Programmatically.

  You could write a simple Java or .Net program to query Stibium and do whatever is appropriate with the results. Again, the results will depend on the client's access rights, which will determine which of the stored data is available to the client.

• Look at the Stibium Persistence File.

  This option is only available to those who have direct access to the web server's file system. The contents of the file will only reflect the current state of nontransient data items.

Yes, the Stibium .Net client library enables .Net software clients to access Stibium's services. This library is based on our port to .Net of the JNDI standard naming and directory interfaces. The .Net client library was updated and re-introduced in the Stibium v3.2.0 release.

This is best done programmatically by writing a small setup program to initialise the dataset as required. It is generally unwise to edit the persistence file manually, because the server maintains various pieces of operational information in the file, which would then be unlikely to be set up correctly.

It is also important to remember that unless you set permissions to prevent it, an external agent may change or delete these items once you have started the server. In addition, if the data objects concerned are within a transient context, this data will be lost when the server is shut down or reset.

Using terms such as directory and file might well be simpler to relate to than terms like context and binding when describing Stibium, but could lead to technical confusion.

The JNDI terminology uses a descriptive model that relates a set of abstractions to each other, of which files and directories are a particularly familiar concrete example. However, they do not reflect the generalisations with which the JNDI model and its specifications are concerned.

It was our original intention to support SOAP encoding, which would have a number of advantages over other solutions. However when we looked 'under the bonnet' in Axis, we could not find a way of performing the 'xml to Object' decoding that was sufficiently decoupled and separable from the rest of the Axis web service mechanics.

There does appear to be a simple way to do the 'Object to xml' encoding (using the Axis SerializationContext class), but not a comparable means of performing the reverse operation. We have considered the possibility of writing a suitable stand-alone SOAP encoding/decoding tool, but this is not, at present, a very high priority.

No, not if this were done without due consideration!

In general it is not possible to insert one xml document into another one without breaking the xml document model and producing a document which is no longer valid. There are three main reasons for this :

1. An xml document should only contain one prolog, and this should be at the start of the document. If one complete document is inserted directly into another, an extra prolog is then inserted at an illegal position.
2. id attributes must be unique in an xml document. So, if an xml document is inserted into another which contains any of the same ids, then these ids, and the entire document, are invalidated.
3. Significant complications can be introduced where namespaces are used.

Stibium deals with these problems by preprocessing any xml fragments to be inserted to make sure these situations do not arise.

By the following means:

1. You must use the XMLPersistenceEncoder.
2. You need to create a PersistenceDelegate for the class whose encoding you wish to customize. This is done by extending the PersistenceDelegate base-class.
3. You should then add environment parameters of the form persistence-delegate[...] to the appropriate context.

   These can either be placed in the persistence file directly, or added programmatically. If they are added to the root context, they will be inherited by all nested contexts.

   The brackets [...] should contain the fully qualified name of the class to be encoded (without quotes), and the value of the parameter should be the fully qualified name of the delegate class to be used.

Note that any PersistenceDelegates that are declared for a context are shared by all XMLPersistenceEncoder instances that are used by that context.

Place a single environment parameter entry in the root context header of the Stibium persistence document. This must be done manually, nominating a chosen global binding encoder, such as:

    <sb:environment>
      <sb:environment-entry name="binding-encoder[]">
        RCRT.Stibium.Encoders.XMLPersistenceEncoder
      </sb:environment-entry>
    </sb:environment>
          

Then, if no other encoder parameters are set, the XMLPersistenceEncoder will be used to process all bindings that are subsequently added to the persistence document.

This is because the binding encoding process is done on the client side, by design. Any custom encoders therefore need to be on the client side classpath, and should not be made accessible to the web application, which you should generally leave alone.

As an aside, you can store a custom encoder class within Stibium as a named item. A client can then load it from the Stibium server over the network, and make use of it that way. This is a good solution.

Any bindings that are subsequently stored will use the new encoder configuration.

However, any bindings that have already been stored will be recovered using the same encoder type that was originally used to store them, whether or not the same one would still be used to encode such items under the new configuration.

This is because the encoder that is used to recover an item is determined by metadata stored with the item in the xml persistence document, and not by the encoder configuration environment parameters.

This obviously means that a Stibium client must have the old encoder class available (i.e. accessible on its classpath) when it tries to recover the binding; otherwise an exception will be thrown.

They are interoperable, provided that the SimpleXMLEncoder encoder is used, this can be configured as the default by ensuring that the root context contains the appropriate environment entry:

    <sb:environment>
      <sb:environment-entry name="binding-encoder[]">
        RCRT.Stibium.Encoders.SimpleXMLEncoder
      </sb:environment-entry>
    </sb:environment>
          

You can determine whether your active account has read/write access to a given context using the methods of the ContextExtension interface.

If you have read access to a context, then you can use the DirContext's getAttributes method (with an attribute namelist argument) to recover the permissions operational attribute. However, this only applies to permissions set locally for a context, if none are set locally for a group, then permissions are inherited from the context's parents.

Yes and No.

The speed of read operations or write operations on transient items are not affected by this feature, as these only need to use the in memory version of the object state hierarchy.

Where a lot of changes are made to nontransient objects in a large document, there is an associated overhead with synchronizing the state of the data stored on the file system, but this is true of all persistent databases. Maintaining all the data in a single document does potentially increase this overhead.

However, in common with some other similar technologies (such as LDAP) the design of Stibium is primarily geared towards situations where read operations are much more frequent than write operations. Given this consideration, in the author's view, the advantage of encapsulating the entire object-state hierarchy in a single file outweighs any competing motives to change the design.

So, the performance will only be affected significantly in those situations where Stibium is used in a way for which it was not primarily designed.

You need to have Apache Tomcat web server installed and working. This can be obtained, together with installation and configuration instructions, from the Apache Website .

You will also need to download, verify and unpack the Stibium distribution, which includes a WAR file. Installing the Stibium web application from this WAR file is straightforward using the Tomcat management web page.

See the Getting Started with the Stibium Naming Server document for details.

You should edit the stibium-config.xml and stibium-accounts.xml configuration files.

It is generally unwise to edit the persistence file manually, as various operational data is stored and maintained in the file by the server. It is usually safe to delete entries from the file, provided that it remains well-formed and valid, but it is usually best to add items programmatically. The exception to this are environment entries, which cannot be added to the persistence document programmatically.

Stibium does not load or retain any xml comments in the file, so any that you add will be lost when the file is updated by the web application.

Stibium is not a relational database and hence does not support SQL operations. Instead its semantics are more like that of a standard computer file/directory system, consisting of hierarchically nested contexts (which are analogous to file system directories), which may contain either bound values or nested subcontexts.

These contexts and bound values can be accessed using the standard API functions available on the javax.naming.Context interface. Simple attribute-matching searches that are a part of the javax.naming.directory.DirContext interface are also supported by Stibium.

In addition, the internal data storage mechanism used by the Stibium server is xml-based, and has been designed for use with xpath. This means that select-like operations can be executed on the Stibium dataset using xpath syntax. Since xpath is an xml technology, it does not appear in any of the core JNDI interface specifications, and executing these operations requires the use of functions that are specific to Stibium, and are part of the ContextExtension interface.

You need to make changes on both the server side and the client side:

•  Server Side

This requires setting up the web server to use SSL, the Secure Sockets Layer, which requires the server to have a keystore with a valid cryptographic certificate. Instructions can be found on the Apache Website : SSL Configuration : HOW-TO

This step makes the server able to respond to https service requests, if secure communications are always required, you may also want to disable standard http communications (by editing Tomcat's server.xml configuration file).

•  Client Side

For https communications to work, the client must 'trust' the SSL security certificate used by the server, otherwise the SSL communications layer used by the xml web services will fail, and throw a communications exception.

If the server's certificate has been signed by a trusted CA, then it should be trusted automatically.

However, if the certificate used by the server has just been generated using 'keytool', for example, and not been signed in this way, then an extra step is required.

In order to become trusted, the server's certificate must be imported into the cacerts keystore that is part of the java runtime used to run any client programs. For multiple clients, each runtime cacerts must be separately updated.

There are some functions which use metadata stored using the Resource Descriptor Framework (or RDF) standard. These are present because Stibium is also designed to provide ontologically enabled web services to the environments that it supports. These are not currently for general use, but are being used for the author's internal development work; these may be released for wider use at a later date.

This is not a straightforward subject, but the ability to associate RDF data with stored items means that a degree of machine-interpretable meaning can be associated with the data stored by Stibium. This approach facilitates the use of advanced techniques that are rooted in Artificial Intelligence and Knowledge Management systems.