AnsweredAssumed Answered

Musing about Alfresco WCM for web app management

Question asked by bnordgren on Apr 8, 2010
Latest reply on Apr 16, 2010 by bnordgren
I'm responsible for technical planning and implementation of unexpected web needs. My environment is a research lab where the individual scientists may at any time propose to develop a model which has a web delivery component. These may be anything from static files containing prose to a full web app written in Language X. Our goals are not to develop a giant monolithic system, but to support rapid prototyping using the most appropriate tools to the task at hand.

To that end, I like Alfresco's WCM for the following reasons:
  • Openness: Alfresco can deploy to a filesystem target, allowing a totally decoupled system to manipulate, interpret, and/or execute the managed code.

  • Centralization: Alfresco centralizes a reference copy of the code/files, centralizes the records of which versions were deployed where, and offers one central place to control the distribution of code to a handful of well defined target machines.

  • Workflow: Alfresco supports the imposition of workflows on the update of websites.

  • Delegation: Alfresco supports the delegation of responsibility for web projects to a web project owner, so my fingers aren't in everyone's pies.

  • Security: Alfresco supports secure methods of deploying content to our public website outside the firewall. I am not required to hand out shell access to our server in order to allow people to control their little web space.
Clearly, the things I like about Alfresco WCM have nothing to do with content management and everything to do with configuration management. Now the "bad news": the one thing I really don't like about Alfresco WCM is the assumption that all changes must happen within Alfresco. There is no means to change files in a deployment target and commit those changes back to the repository. (Bear with me, I'm not trying to make Alfresco WCM into subversion; I want to keep all the good features listed above, which are nearly diametrically opposed to Subversion and other SCMs.) I would actually prefer that the authoring server be forced to query a deployment target for changes.

Reasons to want to update a web project with changes in a deployment target all have to do with being able to rapidly redeploy a web application exactly as it was at the time of a catastrophic event:
  1. Running the install script in an external system (e.g., Joomla!) changes the file set, and this change needs to be recorded in the web project.

  2. Installing an "extension", "module", "plugin", or whatever else in the external system changes the fileset, and the change needs to be brought into the web project.

  3. The deployed web application supports user-generated content which affect the file set (uploading files/attachments).
I know what you're thinking, but you cannot solve this problem by running the web app off of a CIFS mounted filesystem if your public webserver is outside the firewall and your authoring server is inside. You could, however, create a "deployment target sandbox" on the authoring server which periodically queries the deployment target for updates. The deployment target, of course, needs to support sending "differences" since the last query. Note carefully that all queries originate from within an organizational firewall and connect to an external endpoint.

Now on to my next observation: many of the apps I run, including Alfresco itself, consists of more than files. There is an associated database for Alfresco, Joomla!, Trac, Redmine, and the "custom special purpose" apps. Preserving the state of the web application consists of a common pattern of preserving the files and preserving the associated database. In fact, the database is where the content typically lives. It is not necessary to interpret the contents of the associated database; merely necessary to preserve it. Thus, web projects could contain the entire state of the web application if they had an optional "database dumpfile" property/field/association which was not part of the files deployed to the website. If the deployment target could execute simple preconfigured commands (possibly even defined in a property file) on the target system, the authoring server could ask it for a current database dump during an update, or could instruct it to deploy the given database dump to the database during a deployment.

So to summarize:
  1. Alfresco's current WCM infrastructure works well when the flow of information is always authoring server to deployment target.

  2. For web applications which run in an external environment, there are many valid reasons information may flow from deployment target to authoring server. It would be nice to have the authoring server query a deployment target for changes in its file set.

  3. Modern web apps (including Alfresco Explorer/Share/etc) are almost invariably comprised of a set of files (typically the web application) and an associated database. It would be nice to have a way to associate a database dumpfile with a web project.

  4. Last but not least, I think there would be great utility in making the deployment target capable of using database command line tools to dump and restore the database associated with its fileset.
I think this functionality should be named WAM for Web App Management. :)

Any comments?

Outcomes