Architecture ideas for an Alfresco WCM backed website

[mittaldeepak01]

I am soon to start work on a business magazine website using Alfresco WCM. I wanted to share and validate my ideas about the architecture of the website with the forum; just to make sure that it makes sense and there are no gotchas with the architecture.

Here are some very high level requirements of the application

• Content will be created by content contributors. Content needs to go through standard review and approval workflow before being published to the live site.


• Authors should be able to classify/tag the content into various categories.


• Types of content that will be created : news articles, case studies, slide-shows, etc


• Site visitors should be able to comment on news articles.


• Site visitors should be able to export/download news articles as PDF.


• Site visitors should be able to view content by date, subject, "most read", "most emailed", etc.


• Basic and advanced search

High Level Architecture

• Content production and management will be done using Alfresco web-client to produce news articles, images, case-studies, etc.
• Content Delivery will be done using a java web-application (making use of Grails web framework)


• Front-end Grails app will store all the content meta-data in its own RDBMS and the content files on file-system


• All the features for the site visitors will be build into the Grails app. Grails app will not talk to Alfresco repo in any way.


• Content from Alfresco repository will be published to a File System Receiver (FSR). At the end of the publish/deployment of content, an Alfreso web-script will be invoked to query for the newly created/updated/deleted content items in the repository since last publish process. Using the list returned by the web-script, required insertions/updations/deletions will be made in the Grails managed RDBMS.


• PDF and image renditions will be generated by Alfreso and will be published along with source content using FSR to file-system accessible by Grails app.

I am not sure if this makes sense to Alfresco veterans, but this is that I have in mind. I don't want to use the Alfresco dynamic site/Surf platform for building the front-end site.

Please let me know your thoughts about this. I hope this is achievable and I am not missing any important aspect here.

Regards,

-Deepak

[jbarmash]

Deepak,

    * Content production and management will be done using Alfresco web-client to produce news articles, images, case-studies, etc.
Ok.
    * Content Delivery will be done using a java web-application (making use of Grails web framework)
No problem.  You should also be able to use virtualization server to preview, since this is Java.
    * Front-end Grails app will store all the content meta-data in its own RDBMS and the content files on file-system
If you are managing some of the metadata in Alfresco, then another option you have is to deploy to an Alfresco runtime.  In fact the file system receiver does not copy the metadata along with the content.
    * All the features for the site visitors will be build into the Grails app. Grails app will not talk to Alfresco repo in any way.
Makes sense.
    * Content from Alfresco repository will be published to a File System Receiver (FSR). At the end of the publish/deployment of content, an Alfreso web-script will be invoked to query for the newly created/updated/deleted content items in the repository since last publish process. Using the list returned by the web-script, required insertions/updations/deletions will be made in the Grails managed RDBMS.
This seems weird.  The deployment of content takes care of transferring the updated / created / deleted items over to teh deployment environment, just like Alfresco - Alfresco Runtime deployment does.  It would make more sense if your Grails app query alfresco runtimes in the deployment environment over web scripts to render dynamic content.  If you do decide to go the route of FSRs though, take a look at deployment hooks - they are code you can run after a deployment happens.
    * PDF and image renditions will be generated by Alfreso and will be published along with source content using FSR to file-system accessible by Grails app.
This will not be trivial to do on WCM side, possibly in javascript using transformations. 

By the way, I would suggest you get support.  The WCM has quite many moving pieces and in general is more complicated to architect well than DM side.

[mittaldeepak01]

Thanks for the very useful response jbarmash.

I have some follow-up questions based on your response.

=> You mentioned that FSR does not copy meta-data – but I guess it does copy the XML file which is created by filling-up the web-form. I intend to define my XSD such that all the attributes that I am interested in are in the XML itself. Does that make sense?
=> You mentioned that generation of image renditions and PDF renditions might not be trivial to do on WCM side? I assume that for PDF generation, we would need to define the FO script. And for image rendition generation, some kind of rules (I have seen them on the DM side). I am assuming that the same content rules are available to WCM as well. Is that correct?
=> Regarding invoking the web-script at the of the deployment, I intend to do that using the deployment hooks only. The reason I need to do that is because I will be storing some attributes of the content (passed to content delivery app using FSR) in the RDBMS managed by the grails app. So, I need to know the list of changes that have happened since last deployment process. I also feel most uneasy about this piece, but I don't really want to have an Alfresco run-time as part of the content delivery app.

Thanks for the support suggestion. I am already persuading the client to do that. And just fyi, virtualization does not work with Grails app. I listened about it in one of the webinars - Grails app specifically being mentioned as one of the technologies that does not work with virtualization despite being java; though I could not understand the reason very well.

Thanks again.

[jbarmash]

Sorry for delay in followup - i've been travelling at customer sites.

=> You mentioned that FSR does not copy meta-data – but I guess it does copy the XML file which is created by filling-up the web-form. I intend to define my XSD such that all the attributes that I am interested in are in the XML itself. Does that make sense?

 
Yes, it copies the XML data created by filling out the web form.

=> You mentioned that generation of image renditions and PDF renditions might not be trivial to do on WCM side? I assume that for PDF generation, we would need to define the FO script. And for image rendition generation, some kind of rules (I have seen them on the DM side). I am assuming that the same content rules are available to WCM as well. Is that correct?

  The content rules are not available on the WCM side, unfortunately . However, some of the event handlers that are available on DM side are available on WCM, so you should be able to write an event handler that would accomplish the same thing through JavaScript (better) or Java. 

=> Regarding invoking the web-script at the of the deployment, I intend to do that using the deployment hooks only. The reason I need to do that is because I will be storing some attributes of the content (passed to content delivery app using FSR) in the RDBMS managed by the grails app. So, I need to know the list of changes that have happened since last deployment process. I also feel most uneasy about this piece, but I don't really want to have an Alfresco run-time as part of the content delivery app.

  Sounds good.   Just be careful about storing data in RDBMS - it's not a problem at all, just might be annoying to synchronize DB schema in this case.    I think customes who are using Rails wrote their own implementation of Rails ActiveRecord that makes requests back into Alfresco ASR, though I understand if you don't want to go that route.

[tommorris]

Hello,

I'm very interested your comment Jean

…some of the event handlers that are available on DM side are available on WCM…

Could you expand a little more please? It sounds very useful indeed.

Many thanks.