Beginner Thoughts on Alfresco Architecture

by | Feb 15, 2011 | Alfresco, Alfresco Development, Architecture, Enterprise Content Management, Software Development | 3 comments

If you asked me three months ago if I enjoy developing to Alfresco’s repository and Share UI (specifically Enterprise 3.3.3), it would have been a frustrated “NO…” — Not frustration about WANTING to learn a new product, since that is always exciting and challenging, but frustration on not understanding the architecture, the BIG PICTURE, to know how to use the product.

I’m not going into any deep personal thoughts on Alfresco ECM architecture today; rather I am going to share my thoughts on working with the Alfresco repository and the Alfresco Share UI from a software developer’s standpoint that had (almost) no prior experience with Alfresco, or ECM platforms in general.

I am relatively new to Armedia, and went headfirst into learning Alfresco ECM.  NOTE! It is generally a good idea to get a “crash-course” in a new product from a product expert before jumping headfirst into a new product, even if Alfresco has thorough documentation via their Wiki.  My coworkers and I had the pleasure to have an “Alfresco Architecture Crash-Course” presentation shared with us from Dimy Jeannot who was working on another Armedia Alfresco project.

The high-level architecture is as seen below.  Any numerous UI technology, frameworks, etc are represented by the presentation layer (Alfresco Share, jQuery, EXTJS, etc).  The presentation layer can communicate with the Alfresco repository, or via Alfresco data web scripts (data layer).

High-Level Alfresco Architecture

High-Level Alfresco Architecture

The more detailed Alfresco architecture is seen below; we use the Alfresco Share UI as our example here.  Share, and any custom Share code you write, calls RESTful presentation and/or data web scripts.  These web scripts, in turn, communicate directly with Java Core Services exposed by Alfresco (i.e. document, search, node), or any custom services you may need to add for your application, to communicate with the Alfresco Repository.

Never assume that Alfresco and Share are running on the same server host.  For example, you should not hardcode localhost or any other hostname in your Share code.  Instead, use Share’s proxy URL when invoking a data web script (i.e. from a Share ftl, use Alfresco.constants.PROXY_URI when invoking your data web script -> Alfresco.constants.PROXY_URI + “<URL>”).

Where should you store your web scripts?  If you are concerned with data, store your web scripts in the data layer.  When your data web scripts are deployed, they are stored at webapps\<alfresco webapp context>\WEB-INF\classes\alfresco\templates\webscripts, create custom packages for your application.  Else you are concerned with presentation (such as from a Share dashlet), store your code in the presentation layer (it should then in turn call a data web script to get its data!).  When your presentation web scripts are deployed, they are stored at webapps\<share webapp context>\WEB-INF\classes\alfresco\site-webscripts, create custom packages for your application.

Detailed Alfresco Architecture

Detailed Alfresco Architecture

Looking back now and reading the Alfresco Wiki’s, the Alfresco architecture makes sense, I just needed guidance on putting the big picture together to start feeling comfortable with working with a new product.  If you ask me do I enjoy developing with Alfresco now, I would say yes <with smiles>.


Need a bit more info on how Armedia can help you?

Feel free to schedule a 30-minute no-obligations meeting.


  1. Frances Youban

    In the little work I have done with Alresco, I ran into some hurdles getting the access/authorization security layer to work properly. If I remember correctly, my understanding is these security components effectively sit between the presentation and data layers. Granted, my “pain” wasn’t anything more than I have experienced securing any other system (ECM or otherwise), but I’m curious if you (or others) have experienced anything – positive or negative – with Alfresco in secure implementations, particularly given your lack of much prior experience working with it.

  2. Frances Youban

    As I noted earlier, I’m not sure the issues I encountered had that much to do with Alfresco as opposed to general issues with the overall solution’s security design. I guess I’m trying to say that Alfresco did an adequate job of dealing with security but didn’t make anything spectacularly easier to implement/maintain.

    The problems I ran into were really rooted in the fact that our initial security solution (simple ACLs) was too simple because of complex business logic re: who could access what data/functions under what circumstances. We ended up coding all the access/authorization logic to process all the different situational dependencies instead of using something relatively static like ACLs. Architecturally, it always “felt” like a case where a rules engine like drools would have helped if I could plug it in between Alfresco’s presentation and data layers to perform the necessary security checks, but we were never able to get that to work.

    Again, I suspect our situation is fairly unique, and I doubt other ECM products would have dealt with the complex situation any better. Thanks for the input.


Submit a Comment

Your email address will not be published. Required fields are marked *