Architecture

Application Layers

LogicalDOC is composed of various application layers.

Image 1: LogicalDOC application layers

Layers communicate with each other through the Spring application contexts.

Data Layer

The Data Layer is responsible for resource management. In LogicalDOC DMS, information is stored into three main stores: Relational DB, File System, Full-text Index.

• Relational DB: contains all persistent records needed by the program such as users, groups, documents, etc.
• File System: all document files are maintained in a disk area organized in a particular layout which is described later
• Full-text Index: contains the text extracted from all documents allowing fast searches by content

This layer aims to abstract data handling by handling all physical details regarding storage technologies.

DAOs

DAOs (Data Access Object) are objects used to make CRUD (Create, Read, Update, and Delete) operations on the database in LogicalDOC. For each business entity a proper DAO already exists. For example the business entity Document has its DocumentDAO.

The purpose of a DAO is to make a given business entity persistent, and to provide finder methods that retrieve persisted instances. DAOs methods are transactional, and this behavior is obtained using Spring's Aspect Oriented features.

Storer

The Storer is the component responsible for document file archiving. It organizes files in a way that optimizes disk space and access time. For each document in LogicalDOC the file system is created considering its id: it is divided in groups of 3 digits and for each group is created a sub-folder. Inside the last one is created a sub-folder named 'doc' containing all document's files. In particular, each version has its own file named as version code (1.0, 1.1 and so on).

Image 2: File system layout

Search Engine

The search engine module is basically a facade on Lucene, and is responsible for the full-text index update as well as full-text searches. For each supported language a dedicated index is maintained, the user can search on all languages or on a single language only. In the first case all indexes are accessed, and in the second case only the index of the specified language is accessed.

Normally the index is not optimized to speed-up write operations, so a scheduled task takes care of the index optimization. The index optimization minimizes disk consumption and search response time.

Business Process Layer

The most important processes are identified in this layer which are business entities. These processes are accomplished by managers. A manager is a component that operates on one or more business entities, and accomplishes complex business operations on the entities. For example, the DocumentManager implements the check-in process that involves document creation, content indexing, file storage, and many more processes. Managers use the underlying Data Layer to save/retrieve information to/from the data stores, without knowing anything about implementation issues. This way managers are completely decoupled from the data store internals. The business process layer aims to make a reliable and helpful API (Application Programming Interface) to the upper layers.

Business Entity Layer

In this level layer there is the static model of the application domain. Each business entity is modeled as a Java Bean that represent a primary class concept. Business entities are for example Document, User, Menu, etc. An Entity does not contain any business logic since it is implemented by managers, which make business entities very simple objects. Business Entities and Managers create the API that allows the GUI (Graphical User Interface) components to interact with the DMS engine.

Web Interface

The web interface is the web-application that allows the end-user to interact with LogicalDOC. The GUI of LogicalDOC is completely web-based, and it is implemented using JSF and AJAX technologies.

Web Services

LogicalDOC can be used as middleware, and can be integrated with other system through the use of the built-in Web Service. The Web Service module is part of the LogicalDOC core distribution, and it is compliant with W3C specifications SOAP and MTOM.

Security Model

Following the general product philosophy, the implemented security model is very simple and involves only three entities: User, Group and Menu. Users can be member of one or more Groups, and read/write permissions can be granted to a Group on a Menu. The Menu entity doesn't just model application menus, it also models other concepts such as the folders where documents are stored. All security policies are expressed on Menus only, so any entity that needs security policies needs to have an associated Menu.

Note: In LogicalDOC security policies can be defined only on folders and not on a single file. 
     This design choice is due to performance considerations.

Modular Design

LogicalDOC is not a monolithic application, in fact its design is fully modular as the LogicalDOC core is a plug-in. New features can be added by plug-ins.

Plug-in System

One of the key features of LogicalDOC is its plug-in system. Plug-in is the only means by which the product can be extended. If you want to add features or customize existing ones, you must provide a plug-in. The standard LogicalDOC distribution comprises various plug-ins such as the logicaldoccore and the logicaldoc-webservice. Below is a list of the most important plug-ins for the standard distribution:

Plug-in	Description
logicaldoc-core	Core API
logicaldoc-webservice	Web Service implementation
logicaldoc-webdav	WebDAV support
logicaldoc-external-authentication	External authentication via LDAP specifications: OpenLDAP - MS Active Directory

Optional plug-ins include:

Plug-in	Description
logicaldoc-email	Downloads documents from mail server
Localization Plugins	Add support to a language not found in the base distribution of LogicalDOC. Localizations available via plug-in: Russian, Chinese, Greek, Brazilian, Dutch, Portuguese

Extension Points

Each plug-in can define one or more extension points that can be extended by other plug-ins. For example, the extension point Language defined by the logicaldoc-core plug-in is extended by the logicaldoc-lang-pt plug-in in order to add support for the Portuguese language.

Contributions to the platform

A plug-in can add several functionalities to the platform. This is only a brief list of the most important functionalities:

• Extension of existing extension points from other plug-ins
• Definition of new extension points
• Business entities
• Managers
• i18n translations
• Static resources
• Libraries and technologies

Plug-in Archive

A plug-in is packaged in a compressed zip archive called the plug-in archive. The structure of a plug-in archive is very simple.

Image 3: Plug-in archive

• classes/: contains all the plug-in classes as well as resources that are business entities, managers, etc.
• lib/: contains the needed dependencies (.jar files)
• plugin.xml: This is an XML file of the plug-in descriptors that define extension point definitions

Technologies

LogicalDOC leverages the best of the breed Java technologies. In this chapter we will introduce the most important technologies and describe how they are used in the LogicalDOC platform.

Spring

All DAOs and Managers among the many others fall into a Spring Application Context. Each plug-in can define its own application context simply by placing a resource named context.xml in the class path containing all bean definitions. At the startup, all class path resources named context-*.xml are collected in order to setup the big application context in which all DAOs and Managers defined in each plug-in can reference the DAOs and Managers defined in the other plug-ins. In other words, all beans defined in a specific plug-in are immediately usable by all other plug-ins.

Hibernate

LogicalDOC DAOs are implemented using the Hibernate ORM (Object Relational Mapping) framework. Hibernate abstracts the Data Layer from JDBC issues and alleviates development efforts. Each plug-in can contribute new persisted entities simply by placing the *.hbm.xml file in the class path mapping. At the startup, all class path resources named *.hbm.xml are considered mapping files which are then passed to the Hibernate configuration. Each mapping file is used by Hibernate to persist a Business Entity, e.g. the mapping Document.hbm.xml contains mapping information for the entity Document. As a general rule for the naming of a mapping file for an entity, use <EntityName>.hbm.xml.

Java Server Faces

The user interface of LogicalDOC is based on JSF(Java Server Faces), utilizing the JSF implementation called IceFaces. The main configuration file for the managed beans is the WEB-INF/faces-config.xml, but each plug-in can contribute a new managed bean simply by declaring them as a simple bean inside the Spring application context.