Introduction
This document aims to describe eXo Platform Software architecture. The intended audience is mostly technical staff, developers or team leaders.
What you will find in this document ?
Architecture overview
An architecture overview will present the main conceptual elements and relationships. Those high level schematics should help to represent business and IT capabilities of eXo. More details will be found in the subsequent chapters.
System Contexts
For each major subsystem, we will represent it and its direct environment such as servers or external services.
A diagram will show information and control flows between the system and external.
Component models
For each major subsystem or important module, we will present a diagram that shows the main components of the inner 1architecture.
We will detail represent responsibilities, interfaces and relationships of the components.
What you will not find in that document ?
eXo is a big platform and there are a lot of possible combinations of network of computer systems to provide non functional requirements: performance, scalability and fault tolerance.
It is out of the scope of this document to address this. eXo Platform SAS experts usually help software integrators to define the appropriate operational architecture for their customers.
Chapter 1: General Architecture Overview
This chapter draws shortly the environment of the eXo Platform and its main components.
eXo Platform System Context Overview
The eXo platform integrates to the EIS as a server-side component within an java application server.
Most client accesses to the platform are done through HTTP via a simple web browser.
Communication with existing infrastructure is achieved through standard protocols and technology.
Although, eXo platform can come fully bundled (no other software is required), a typical deployment will reuse enterprise infrastructure such as:
- Database server : a relational database for JCR metadata and workflow engine
- Mail server : to send and receive emails
- Directory server: to store platform users, groups and roles
- Authentication / Single Sign On (SSO) server
Within the platform, foundational runtime components provide technical foundation:
- PC : as the portal applications runtime container
- JCR : as the main content storage
- WS : as the web services integration stack
On top of this, a number of packaged software suites address different enterprise needs around:
- Business applications : Portal provides UI management for portlets and widgets that run on top of existing business applications
- Content management : eXo Enterprise Content Management (ECM) provides applications to capture, store, manage, deliver and preserve enterprise content
- Collaboration: The Collaboration Suite (CS) provides applications for personal or team communication and collaboration
- Knowledge : The Knowledge Suite (KS) provides applications for enterprise knowledge management and sharing
- Live communication : Liveroom provides a realtime collaboration suite of applications
Other infrastructure may be used in some deployments such as: Web Server, SAN, NAS, streaming or instant messaging server. This will be elaborated in the appropriate sections of this document.
Other client access technology is also available and will be detailed in the following chapters.
This diagram shows the main building blocks of eXo Platform. This document will detail the inner architecture of each.
eXo platform is built on top of a component container Kernel often called eXo Container.
The Core Services module contains general services available all over the platform.
The Portlet Container, Java Content Repository and Web Services Stack are the necessary runtime blocks.
The Portal is the primary UI layer that allows managing portals, applications and pages.
The Enterprise Content Management brings content management and workflow portlets to the portal.
The Collaboration Suite offers a set of common collaboration portlets such as webmail and share calendars.
The Knowledge Suite focuses on knowledge sharing among the enterprise by bringing forums, faq, blogs and wiki applications.
Liveroom is dedicated to real-time communication between portal users.
Chapter 2: Software suites architecture
This chapter will go through all introduced software suites and cover their architecture.
Portal
Portal is the primary software suite of eXo platform.
It is mandatory to run any of the complementary eXo software suites.
The portal is responsible for UI management, personalization and aggregation of enterprise content and business applications.
Portal Context
Portal stores its model (portals, pages, navigations, preferences....) within the Java Content Repository.
Applications' runtime is supported by eXo portlet Container which may communicate with an external remote portal through WSRP.
Portal authentication relies on standard JAAS Login modules. Authorization is based on eXo organization model than can be hosted within a database or a, ldap directory.
Portal Components
Portal has two main components:
- Portal Engine: that takes care of pages, navigations and preferences.
- WebUI framework: a portlet Web framework tailored for easy screen composition and ajax support in portal environment.
The portal comes with a set of handfull webui portlets designed for Administration or end User purposes.
WebUI or third party portlets use the standard Portlet APIs (JSR 168 or JSR 286). Remote portlets can also be integrated through WSRP.
Enterprise Content Management (ECM)
The Enterprise Content Management (ECM) suite aims to make content management easy at the enterprise level.
ECM Context
ECM leverages JCR standard features such as versioning, locking, nodetypes and mixins and brings UI to manage structured or unstructured data.
Content sharing and permissions management is available through the OrganizationService.
The ECM needs to use SMTP to send document and workflow notifications to users.
The workflow storage may (JBPM) require a relational datasource. Note: Bonita storage has been ported to JCR.
ECM Components
ECM Ships 5 applications:
- The File Explorer is a customizable application to manage files and structured content.
- The Content Browser is used to display the content.
- The ECM Admin allows managing all aspects of the ECM engine (see below).
- The Workflow Controller let users follow and advance the manual tasks of the running business processes.
- The Workflow Admin allows to get history and upload new versions of the business processes.
The Workflow Engine is responsible to run Business Processes either started manually by users in Workflow Controller or automatically within ECM.
The workflow engine is abstracted enough to allow different runtimes. So far, Bonita or JBPM implementations can be used.
Business processes are deployed within the ECM and must conform to standard process definition languages such as xpdl (bonita) or jdpl (jbpm).
ECM Engine details
he ECM engine leverages JCR advanced features to provide a rich set of functionalities.
Authoring:
- Versions: allows managing versions of nodes such as defined by JCR. ECM comes with UI to show and manage version trees. Note that office plugins support automatic version management.
- Locks: Locking/unlocking features are based on JCR locks and available through the UI. Note that WebDAV access supports automatic lock acquisition.
- Permissions: Fine grained permissions are available at node level. They leverage the eXo organizational model (users, groups, roles).
- Relations: JCR references are leverages as relations in ECM. It is possible to link different contents of the repository. ECM provides UI for management of relations and easy link navigations.
Classification:
- Folksonomy: provides tagging support on content. It is based on JCR references.
- Taxonomy: provides content classification in a hierarchical manner. It is based on JCR references.
- Queries: JCR querying features are fully available. Stored query can be managed and replayed. Queries can be shared or kept private. They can also be reused as input of Content Browser.
- Metadata: JCR mixins are leveraged to offer metadata management on content. Dublin core standard metadata set is automatically extracted from office documents. Custom metadata can be added and managed.
Collaboration :
- Comments: A simple service is available to follow comments on produced contents.
- Votes: A simple service is available to evaluate produced content
- Watch: It is possible to be notified of a documents changes
- i18n: internationalization features are available for structured documents.
Publishing :
- Template: a templating service based on JCR nodetypes allows defining new document types with input forms and rendering templates. The templating mechanism is used in File Explorer, Content Browser and Workflow Controller applications.
- RSS: a feed publishing service allows publishing RSS feeds based on JCR queries.
- Records: A full records management service that implements
User Interface:
- Drives: are configurable entry points to the JCR. A drive allows customizing the File Explorer JCR to show only relevant toolbar and a subtree of the JCR. Drives define ACL necessary to view them.
- Views: File Explorer look and feel is totally editable as well as Content Browser templates.
- Scripts: Groovy scripts are available in many places in ECM. It allows customizing easily the behavior.
- Actions: ECM actions allow to trigger scripts or Business processes within the ECM when JCR events are cached (ex: when adding a node within a subtree)
Collaboration Suite (CS)
The collaboration suite contains communication tools with team collaboration enabled.
CS Context
The collaboration Suite runs as a set of webui applications within portal.
It relies on an external Mail server for emails in eXo Mail application as well as other email notifications within the suite.
The contact manager is sourced on eXo organizational model thus allowing access to the enterprise directory.
Also, calendars and address books sharing use the organizational model through Organization Service.
CS Components
There are 3 applications in CS.
- eXo Contact Manager: the address book manager application
- eXo Mail: the webmail application
- eXo Calendar: the agenda manager application
All of them are decoupled from a respectively reusable service.
- Contact Service is reused in all CS applications. It supports vcard format for contacts.
- Mail Service is also reused in all CS applications and deal with SMTP, IMAP and POP protocols.
- Calendar service is used in the Mail and Calendar applications. It supports import/export iCal. It relies on Mail service for user notifications.
Finally all CS persistence such as contacts, emails events and tasks is done on top of the JCR.
Knowledge Suite (KS)
eXo Knowledge Suite focuses on knowledge sharing in the enterprise.
KS Context
The Knowledge Suite runs as a set of webui applications within portal.
It relies on an external mail server for various email notifications such as moderation or topic watching.
Again, the Organization Service drives sharing and permissions management.
The data storage is fully handled by JCR.
KS Components
So far, KS is made of 2 applications:
- Forum: The forum management application
- FAQ: The Frequently Asked Question application
Both have an independent service, respectively Forum Service and FAQ Service.
Both use the JCR API as their storage facility.
There are no relations with the two applications or services.
Liveroom
Liveroom is a suite of integrated realtime collaboration applications for eXo.
Liveroom Context
The Liveroom suite runs as a set of portlets within the portal.
As usual, sharing and permissions are managed by the Organization Service.
The JCR serves as the permanent storage.
Chat services require the use of a jabber server and videoconference and whiteboard relies on red5 server flex streaming technology.
Liveroom Components
Liveroom is made of 3 applications:
- Chat: is an instant messaging client
- Whiteboard: allows realtime whiteboarding
- Video: is a video conferencing application
Chat application is a webui portlet decoupled from its Chat Service.
Cometd Service is a server push technology to provide realtime updating of the chat client.
Whiteboard and Video both use the same Liveroom Service.
JCR is used for persistent storage such as chat conversations and whiteboard charts.
All applications use a REST binding of the Organization API.
Chapter 3: Low-level components architecture
This chapter will describe the lower-level modules of the platform bottom up.
Kernel
Kernel is the common denominator of all other modules. Almost any component of the platform has a runtime dependency with it.
The main component is eXo container which is an IoC container (currently based on Pico Container) where all runtime components live.
The eXo Container also provides XML Configuration and Plugin facilities to the hosted components.
All services are automatically wired as JMX beans to help monitoring.
The Kernel module also offers facilities for Logging, Monitoring and Cache management.
Core Services
The Core Services are common services available to all over the platform.
The main component is the Organization Service. It is an abstract API that currently has two distinct implementations :
- LDAP Organization Service: that maps the organizational model to an ldap directory with the help of LDAP Service (built on JNDI)
- Database Organization Service: that maps the organizational model to a relational database with the help of Hibernate Service.
The AuthenticationService is used by the default jaas login module shipped with the portal. It performs authentication against the Organization Service.
Web Services Stack (WS)
The Web Services Stack module is aimed at helping integration with existing services.
All web services components live in eXo Container.
The main component is REST Core which is eXo implementation of JAX-RS (JSR311) standard.
It allows virtually any eXo Container service to offer REST API. The EJB Connectors allows such services to be also exposed as EJB 2.1 or EJB3 3 beans.
A JSON Framework (JavaScript Object Notation) allows transforming java objects into json to be easily consumed by javascript client applications. It is very convenient for widgets.
The XFire Connector brings SOAP webservices to the platform. It allows virtually any JSR181 annotated service running inside the eXo Container to be exposed as a SOAP web service.
The Cometd service is a server to client push service that eXo platform uses mainly for notification directly to the client (reverse-ajax).
Portlet Container (PC)
The Portlet Container is standardized the runtime container for the applications exposed in the portal.
The Portlet Container Service runs within the eXo Container. It provides an abstract application lifecycle management API.
Actual runtime support is provided by the mean of plugins.
- Portlet API plugin: supports both standard portlet APIs 1 (JSR168) and 2 (JSR286).
- WSRP plugin: supports WSRP applications
- WSRP2 plugin: supports WSRP2 applications
Java Content Repository (JCR)
The Java Content Repository is the central standardized persistence component. It is used extensively by eXo applications.
eXo JCR fully implements Java Content Repository standard (JSR170). It provides higher level data services.
All components of eXo JCR run as eXo Container components.
Persistence is based on a relational database and any jdbc compliant Database Server can be used.
Value Storage is pluggable and can use database BLOBS, file system (NAS or SAN) or even Amazon S3 online services.
As a critical integration components, eXo JCR goes beyond the standard and offers extended connectivity to major protocols:
- WEBDAV: is an extension to HTTP targeted to content management. It is used under the hood by our MS/Open Office plugins and by Windows 'Web Folders'
- CIFS: Is Microsoft Windows Share protocol. It allows to view the repository as a Windows 'network drive'.
- FTP: Allows any FTP client to manage file content directly within the JCR. The repository provides an FTP server.
