UsingJakartaSlide

Using Jakarta Slide

Dec 5, 2004

Configuration files

Services / Stores

Slide can store the data it manages in a broad array of repositories. Each repository is accessed through a module called a Service or a Store. Each of these services have widely different dependencies, and can need a lot of extra setup steps. It is expected that services will be developed by Slide adopters to address their specific content management needs. For example, one company would want to access its website and NFS file server through Slide, so a NFS Service will be needed, along with a HTTP service.

The scope of the Slide project is not to integrate every existing repository in the universe (although there will be out-of-the-box support for the most widely used ones), but to enable users to easily write services which would enable access to them.

Default services included with Slide are:

The Domain configuration file

Sample configuration file : [WWW] Click Here

Slide needs a configuration file to initialize the Domain. This configuration file defines the namespaces which are part of this domain, the services associated with them, and the namespaces data configuration. This file uses the XML language for its syntax.

A domain is an aggregation of one or more namespaces. If we use the UNIX filesystem analogy, a domain represents the root ("/") anchor where filesystems (in this case, namespaces) are mounted.

The domain controls access to its registered namespaces and performs initialization and connection management on behalf of the namespaces.

When Slide is first initialized, the Domain configuration is loaded. Once again, if you are familiar with UNIX, the domain configuration file is the equivalent of the fstab file. The path to the domain configuration file is given through the org.apache.slide.domain property in your slide.properties file (which must be located somewhere in your CLASSPATH).

The domain configuration is written by an administrator and tells how to initialize each Namespace. The namespace initialization includes information like:

Jakarta Slide core API

Architecture

The Slide architecture is a matrix of modules, ranging from high-level to low-level services, clearly separating functionality around different aspects (content, structure, security, locking and versioning).

Content in Slide is organized in Namespaces, which contain a hierarchical tree of information (analogous to directories and files in a filesystem). Multiple namespaces are aggregated in a Domain. The default implementation of a Slide domain is as a static entity, so only one domain can exist per JVM.

The high-level interfaces (Helpers) are meant to provide a simple, standardized way of manipulating a namespace from a client application. Underneath these interfaces lie pluggable, low-level services (Stores), which take care of actual storing the information.

/image/ Overview of the Slide architecture

Stores

Stores are low level services that handle the actual storage of content and related data. Stores are totally pluggable, enabling the use of the most appropriate storage method for the type of data to store.

Two different kinds of services exist:

This distinction has been made because it's easy to see that while some repositories are very efficient at managing and indexing small amounts of data (relational databases are a good example of this), others are best for storing big chunks of data (for example filesystems).

Within Slide, every object can possibly have a different kind of backing low-level service. For example, some objects might be stored in a remote LDAP directory, while others could be stored in an local SQL database. Thus, the content of a namespace can be distributed across several different descriptors and content stores.

It is up to the administrator to choose how objects will be stored using the Slide configuration file, which maps low-level services to individual nodes in the namespace.

Services are attributed to nodes in the namespace. This mapping is automatically inherited by sub-nodes. Here is an example of how one namespace might be mapped into different low-level services:

/image/ Namespace mapped to multiple stores

It is obvious that decent transaction capabilities are required in each individual store as well as across all the stores. Slide provides it's own transaction manager based on the Java Transaction API (JTA) to comply with this requirement. Operations that include multiple objects and span various stores can be grouped in transactions and rolled back if one of the operations fails.

/image/ Transactions in Slide

Helpers

Slide also provides a higher level abstraction of the content management system through a set of Java classes, called helpers. These encompass all the functionality a client application will need, clearly separated by aspect. These high-level services allow an application to access content in a uniform fashion, no matter where it might be located, or how it is physically stored.

Tight dependencies exist between the high-level services because of the need to enforce security, locking and other constraints throughout the client API.

The following helpers are provided:

Instances of these helpers for a specific namespace can be obtained through the NamespaceAccessToken that you receive when accessing the namespace.

Content Interface

|Method | Summary | | void create(SlideToken token, java.lang.String strUri, boolean isVersioned) |

Structure Interface Structure helper. Provides methods to manage and navigate the hierarchy of nodes in a namespace. Method Summary

NodeRevisionDescriptors class Method Summary (package private) void addSuccessor(NodeRevisionNumber number, NodeRevisionNumber successor)

(package private) void removeSuccessor(NodeRevisionNumber number, NodeRevisionNumber successor)

(package private) void setLatestRevision(NodeRevisionNumber number)

(package private) void setLatestRevision(java.lang.String branch, NodeRevisionNumber number)

(package private) void setOriginalUri(java.lang.String originalUri)

(package private) void setSuccessors(NodeRevisionNumber number, NodeRevisionNumber successor)

(package private) void setSuccessors(NodeRevisionNumber number, java.util.Vector successors)

(package private) void setVersioned(boolean useVersioning)

NodeRevisionDescriptor class Method Summary

(package private) java.util.Hashtable getProperties()

(package private) void setBranchName(java.lang.String branchName)

(package private) void setDefaultProperties(java.util.Enumeration defaultProperties)

(package private) void setProperties(java.util.Hashtable properties)

(package private) void setRevisionNumber(NodeRevisionNumber number)

NodeRevisionNumber class Method Summary (package private) NodeRevisionNumber cloneObject()

Definition Node 1. Domain.xml Definition Node

From my understanding, the definition section sets where all the data concerning different parts of Slide will be stored. In the example all sub-stores (lock, content, etc...) are stored using "org.apache.slide.store.txfile.[WWW]TxXMLFileDescriptorsStore", which essentially stores data in an XML formatted file.

<definition>

</definition>

To setup Slide with multiple Store Definitions see MultiStoreConfig

1.1. General Store Information

Stores are low level services that handle the actual storage of content and related data. Stores are totally pluggable, enabling the use of the most appropriate storage method for the type of data to store.

Two different kinds of services exist:

This distinction has been made because it's easy to see that while some repositories are very efficient at managing and indexing small amounts of data (relational databases are a good example of this), others are best for storing big chunks of data (for example filesystems). Within Slide, every object can possibly have a different kind of backing low-level service. For example, some objects might be stored in a remote LDAP directory, while others could be stored in an local SQL database. Thus, the content of a namespace can be distributed across several different descriptors and content stores. It is up to the administrator to choose how objects will be stored using the Slide configuration file, which maps low-level services to individual nodes in the namespace. Services are attributed to nodes in the namespace. This mapping is automatically inherited by sub-nodes. Here is an example of how one namespace might be mapped into different low-level services:

1.2. Parameters

1.2.1. Cache Parameters

<parameter name="cache-mode">cluster</parameter>

Caching mode should be set to "cluster" when you want every change in the file system to be immediately displayed in Slide. Other options for this parameter are not yet known - if you know it please add / elaborate here

For more information see CacheConfiguration.

1.2.2. Locking

<parameter name="tlock-timeout">120</parameter>

This determines how many seconds pass before your Slide session times out?

1.2.3. Rootpath

<parameter name="rootpath">store/metadata</parameter>

1.2.4. Cache Timeout

For Slide 2.2 and above you can add this parameter for more caching with a timeout (100 sec in this case)

<parameter name="cache-timeout">100</parameter> <parameter name="cache-mode">full</parameter>

1.3. Scope

"You need to add the scope to have the store (tx) visible."

<scope match="/" store="tx"/>

"So far, you can choose to configure the <scope> tags either directly underneath each store, or put all the <scope> tags at the bottom of configuring all your stores at this time. Soon there will be a standard and expectation, but for now lasse faire."

Basically this determines how you access your Slide applicatio. In the above example accessing the Slide application would be: [WWW] http://localhost:8080/tx

1.4. General Store Definition Information (Low Level Services)

This describes low-level services configuration for the store. (For some reason, it was decided that these low level services also be called "stores" - this makes it a bit confusing.)

<contentstore classname="org.apache.slide.store.txfile.TxFileContentStore">

"classname" specifies the class that implements the sub-store in question. This hints at developers being able to create their own custom store, which is was Slide was designed for from the beginning. For more information see the CreateNewSlideStore entry.

The following are sub-store class implementions that are built into Slide -

TxFileContentStore

[WWW]TxXMLFileDescriptorsStore

[WWW]JDBCStore

FileSequenceStore

From my understanding (please correct me if I'm wrong), you have the following choices in regard to low level services related to stores.

  1. Define the low level service by associating it with the appropriate concrete class

<securitystore classname="org.apache.slide.store.mem.TransientSecurityStore"/>

  1. Define a low level service that can be referenced by other low level services as seen in nodestore

<nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore">

</nodestore> <securitystore>

</securitystore>

"The reference means that for the security store the same object is used as is, is configured at the node store." To get a better understanding compare the default nodestore definition (above) and the nodestore definition using JDBC. The default nodestore stores all of its data in XML format text files while the nodestore below stores the data in predefined tables.

1.4.1. callback-store Parameter

<parameter name="callback-store">org.apache.slide.store.simple.WebdavFileStore</parameter>

1.4.2. rootpath Parameter

This is where all the resources in the "files, content, etc..." collection go to

<parameter name="rootpath">c:/tmp</parameter>

1.5. Content Store Low Level Service

<contentstore classname="org.apache.slide.store.txfile.TxFileContentStore">

</contentstore>

1.6. Node Store Low Level Service

1.6.1. Default File Based Node Store Low Level Service

Using the default node store, will have the namespace's data be stored in XML formatted text files.

<nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore">

</nodestore>

1.6.2. JDBC Node Store Low Level Service

Of course, for ease of maintenance most people will probably want to use a database to store most of the data related to a Slide namespace. In the example below, most sub-stores (except content) are using the JDBC configured nodestore.

Note

If you want to try a JDBC nodestore you also have to create all the necessary tables and views that Slide expects. You can use the scripts (configured for most major database servers) found in jakarta-slide-2.1-tomcat-5.0.28/webapps/slide/db-schema/ (for 2.1).

<nodestore classname="org.apache.slide.store.impl.rdbms.JDBCStore">

</nodestore>

<parameter name="driver">org.postgresql.Driver</parameter>

Put the name of the jdbc driver you want to use here.

<parameter name="url">jdbc:postgresql://19.26.54.86:5432/db_name</parameter>

The database url varies by database and jdbc driver. Consult the accompanying jdbc documentation.

<parameter name="user">test</parameter> <parameter name="password">12345</parameter>

A username / password combination that can access the database.

<parameter name="dbcpPooling">true</parameter> <parameter name="maxPooledConnections">10</parameter>

This enables DBCPPooling and specifies the number of connections it can have.

<parameter name="compress">false</parameter>

I believe if you set this true, Slide will compress (using zip) incomming data and uncompress outbound data. This is quite useful.

1.7. Sequence Store

1.8. Security Store

1.9. Lock Store J2EEStore In order to use the J2EE stores, the Domain.xml file needs to contain the following configuration for the store:

<definition>

</definition>

where the adapter determines which database adapter you want to use. In this case you configured the MySQL adapter. Most adapters have a parameter to decide whether the content shall be compressed (zipped) before storing to the database. This might be fast in some enviroments. This option is switched off here.

You have to create the tables of the database schema manually. Schemata are available in src/conf/schema if you have the source distribution or in slide/db-schema if you have the Tomcat bundled or binary distribution.

If your store is not configured using a datasource looked up using JNDI you will have to provide more information to Slide like this for example:

<definition> <store name="MySqlStore">

</definition>

You can see you will have to configure you driver, the connection url and the user for the database. You can optionally configure if connection pooling using DBCP is enabled or not and if enabled how many connections shall be pooled. If you want you can also choose the isolation level of your database. SERIALIZABLE is a safe choice, but - depending on you database - at least READ COMMITTED is recommended. Locks Needed 1. Table of accesses per method

Method Read Write Implemented COPY source uri recursive target uri recursive YES DELETE target uri recursive target uri recursive YES GET like head - YES HEAD uri - YES MKCOL like put like put without calls to history folder YES MOVE source and target uri recursive source and target uri recursive YES OPTIONS like head - YES POST like head - YES PROPPATCH uri uri and history sub folder YES PUT uri and history folder uri and direct parent, history and sub folder when resource is put under version control, subfolder when already under version control YES VERSION uri and history folder uri and history and sub folder YES REPORT uri und history folder - YES CHECKIN like checkout like checkout YES CHECKOUT uri und history folder uri and history sub folder YES UNCHECKOUT like checkout like checkout YES SEARCH global - YES PROPFIND source uri and descendants if depth > 0 - YES LOCK like head uri YES UNLOCK like head uri YES ACL uri uri and history sub folder YES SUBSCRIBE - - n/a UNSUBSCRIBE - - n/a POLL - - n/a NOTIFY - - n/a MKWORKSPACE ? ? tentative as global write lock UPDATE ? ? tentative as global write lock LABEL ? ? tentative as global write lock BIND ? ? tentative as global write lock UNBIND ? ? tentative as global write lock REBIND ? ? tentative as global write lock