Content Server serves content to applications, which in turn provide friendly interfaces to human users. Content Server brings the stored content and metadata to life and manages its lifecycle. It exposes a known interface for using the content while hiding the details of how and where files and metadata are stored.
The term Content Server is used in two contexts — the Content Server software that is installed and resides on the file system and the Content Server instance, which is the running process that resides in memory and serves content at run time. However, there is little chance of confusion since the usage is often clear from the context and the term Content Server is typically used without additional qualification (software or process/instance).
A Content Server instance is dedicated to and manages only one repository. However, we will see later in architecture discussion that multiple Content Server instances can be dedicated to the same repository. This is typically done for performance reasons where the multiple Content Server processes divide up the load for serving content from the same repository. The following figure shows two Content Servers serving one repository:
Content Server is the foundation of the Documentum platform and provides the following services:
1. Content management services
2. Process management services (workflows)
3. Security service for content and metadata in the repository
4. Distributed services
These features are described here briefly and in more detail in later chapters.
Content Management Services
Content management services include library services (checkin and checkout of objects stored in the repository), version control, and archiving. The Content Server uses an object-oriented model and stores everything as an object in the repository.
Metadata can be retrieved using Document Query Language (DQL), which is a superset of Structured Query Language used with databases (ANSI SQL). DQL can query objects and their relationships, in addition to any database tables registered to be queried using DQL.
Data dictionary stores information about object types in the repository. The default data dictionary can be altered by addition of user-defined object types and properties. Properties are also known as attributes and the two terms are used interchangeably to refer to metadata.
Virtual documents link multiple component documents together into a larger document. An individual document can be part of multiple virtual documents. The assembly of virtual documents can also be controlled by business rules and data stored in the repository.
Collaborative services can be deployed with an optional license and make collaboration features available in client applications. Collaborative features (Documentum 5.3) include:
Room: This is a secured area within a repository with defined membership and access restrictions.
Discussion: This is a comment thread associated with an object.
Contextual folder: This is a folder with attached description and discussion.
Note: This is simple document with built-in discussion and rich text content.
Note
Documentum 6 is expected to introduce new collaborative features such as polls and calendars.
Retention Policy Services (RPS) is an optional product and enables use of policies to manage the lifecycle of the objects stored in the repository. A retention policy defines the phases through which such an object passes and how it is finally disposed of or exported.
Process Management Services
Process management services (features) include the following:
Workflows: Workflows typically represent business processes and model event-oriented applications. Workflows can be defined for documents, folders (representing the contained documents), and virtual documents. A workflow definition acts like a template and multiple workflow instances can be created from one workflow definition.
Lifecycle: A lifecycle defines the stages through which a document passes. For each stage, prerequisites can be defined and actions can be defined that are performed prior to an object's entry into that stage.
A repository uses access control lists (ACLs), also known as permission sets, as the security mechanism by default. The repository security can be turned off as well.
While the repository security model is ACL, each object has an associated ACL. The ACL provides object-level permissions to users and groups.
When the repository security is enabled, the Content Server enforces seven levels of basic permissions and six levels of extended permissions. There are additional privileges and security components, which are discussed in later chapters.
Content Server provides robust accountability and capability via auditing and tracing facilities. Auditing can track operations such as checkin or checkout that have been configured to be audited. Tracing can provide detailed run-time information useful for debugging applications.
Electronic signatures can enforce sign-offs in business processes. A sign-off is a way of authorizing or approving a decision similar to signing off on paper.
A Documentum installation can include multiple repositories and the Content Server is aware of distributed configurations that deployments can take.
The Content Server provides an application programming interface (API) and therefore needs a layer in front of it to expose its capabilities to human users. Documentum provides desktop and web-based client applications and supports creation of custom applications of either type. The following figure shows several client applications:
The full set of Content Server features is exposed via Documentum Foundation Classes (DFC) and Documentum Client Library (DMCL). DFC provides the API for interacting with the Content Server programmatically.
Documentum also provides a Web Development Kit (WDK) to facilitate development and customization of web-based client applications.
Documentum provides two interactive utilities for interacting with the Content Server using queries — IDQL and IAPI. These utilities are typically used by administrators and developers.
