Liferay extension deployment topologies

Document created by jpotts Moderator on May 10, 2016Last modified by alfresco-archivist on Aug 31, 2016
Version 2Show Document
  • View in full screen mode
  1. REDIRECT Portlets

In Program JCR (embedded)

An application may choose to load a repository in an embedded fashion.  In this case the repository runs in the context of the application hosting it.  When the application has finished execution the repository is no longer available. 

An application wishing to use alfresco JCR in an embedded way must load the repository and request a implementation for the JCR component from spring framework.

JCR as a J2EE Server Resource (JNDI)

Alfresco can be made available to the entire J2EE application server as you would typically make a database available in J2EE.  This is accomplished by loading the repository in one context which is able to register with a proxy registered in JNDI or by having the server start the repository via whatever resource factory mechanism it supports.

In either case the Alfresco JCR repository component is registered in JNDI and can be acquired by other contexts/applications.


Apache Jackrabbit has completed a RMI wrapper for the JCR interface.  With the aid of the JCR RMI extension Alfresco's JCR repository component can be wrapped in a server object and registered with RMI infrastructure (RMID, RMI Registry).  JCR RMI clients can the access the remoted alfresco repository naturally through RMI.

Some Related Deployment Models


Federated Repositories

Repositories can be made to replicate bi-directionally based on a service oriented concepts via web services technology.  Web services over provide a strong mechanism for traversing firewalls which tend to be a barrier in distribution.

This capability allows for large repositories to be constructed in highly distributed, geographically distant deployments while still maintaining a the speed of a local repository (because it is local ... and distributed )

Central Repository Hub and Spoke

Most organizations maintain a 'system of record.'  Even when content and data has been replicated to many different end points, it is still often important to have a system which serves as the master, as the system of record for the data/content.  This system may be a federation, which is a distributed approach to centralization.

This model is commonly referred to as Hub and spoke.  While some systems will maintain a bi-directional replication, many will opt for the central system to replicate to the end point only.