Beginner Thoughts on Alfresco Architecture

Originally posted on February 15th, 2011.

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

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 + “”).

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\\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\\WEB-INF\classes\alfresco\site-webscripts, create custom packages for your application.

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 .