Open Source
Alfresco Architecture at City of Lausanne
Posted 09 Jan 2008 by Optaros in OPEN SOURCE Tags: Alfresco, Architecture, SOA, Open Source, Platform, ECM, Analysis, Recommendations, Government, eGovernmentIn November 2007, we delivered the final presentation of our work for City of Lausanne (Switzerland). The objective of our work was to analyze their needs and to recommend a high level architecture for implementing Alfresco as their core DMS solution.
Context
Ville de Lausanne is an Alfresco Customer who had a previous experience in building an Alfresco prototype. He is currently looking for implementing Alfresco as his DMS Enterprise solution for managing all content/document related needs. The Client asked Optaros to perform an analysis study of their needs and recommend an Alfresco Architecture in the context of his environment Ville of Lausanne is using a virtualized environment (VMWare). Current system environment is as follow: * Windows 2003 as OS * Oracle as database * Active Directory as Enterprise directory Future systems/solutions considered are: * Sun IAM (Identity Access Management) and LDAP * Oracle (most probably) as Business Process engine and IDS Scheer as modeling tool * Enterprise Service Bus solution * Business Intelligence solution
Output
Our work has been performed in a series of three interviews: first focussing on functional needs and two others focussing on technical aspects. Technical subjects to cover were divided as follow: * Connectivity - how to acces the content repository * Security and LDAP integration * Number of repositories * Infrastructure * Sizing * Backup and restore * Migration For each aspect we provided a recommendation based on the current situation and expectations. A final presentation was planned for us to present the output of our work. CONNECTIVITY We discussed standard connectivities - CIFS, webDAV and FTP - as well as APIs to interact with the content repository. Our recommendation was to implement an abstraction layer (web services) to simplify integration of external applications requesting for business services. Security and LDAP integration We discussed two models to manage security: 1/ replicating the LDAP security model into Alfresco and 2/ managing security from the business application accessing Alfresco, thus using an application account to access Alfresco. The recommendation was to have these two models if business requirements required it, but keeping them separate and not mixing them into the same Alfresco instance. This leads us to the next topic of discussion. NUMBER OF REPOSITORIES The main question to address was: "how many instances are needed?". The discussion was around one versus several instances: "what is the criteria to decide to split?". The key driver for having several instances was the SLA. Another major point is the level of dependency of contents/documents between applications/projects. When several applications have content that is not linked, has no association or is not shared, there is no contraint having these applications in a same instance. Based on the Customer needs, we recommended at least three type of instances: 1. for business application 2. for public citizen application 3. for collaborative spaces INFRASTRUCTURE We made the recommendation of: * having the Alfresco instances on their virtual servers (VMWare) * having their database in a dedicated server * having the Alfresco content store on the SAN SIZING Based on the JCR/MySQL benchmark we did, we proposed basic metrics from where the Customer can size, per application, the Alfresco implementation he needs: * Red Hat RHEL AS 4 64 bits or Windows 2003 similar as OS * 2 Dual Cores Opterons 2.6 MHz as Processor * 8 GB RAM (4 GB for JVM) as Memory BACKUP AND RESTORE For applications that require medium SLA (without high availability), the Alfresco warm-standby configuration can be considered. However in a virtualized environment, complex mecanisms are not needed anymore. MIGRATION We discussed several options for migration using ACP packages, CIFS copy or web services. Our recommendation for migrating existing data was: * structure existing data * package into ACPs using a script or using ACPGeneratr tool when metadata exist ouside the document * deploye ACPs into Alfresco The feedback of the Customer was very positive. He appreciated our work, our expertise and our ability to testify of other practical experiences.
Submit a comment