topic Re: Musing about Alfresco WCM for web app management in Alfresco Archive

Musing about Alfresco WCM for web app management

bnordgren — Thu, 08 Apr 2010 18:03:56 GMT

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 ap

Re: Musing about Alfresco WCM for web app management

mrogers — Thu, 08 Apr 2010 23:22:42 GMT

I hope some of my colleagues come in on this thread since they will be able to put forward slightly different perspectives.

Here are some points in response:
* User Generated Content - being able to pull back UGC from a runtime environment is something we know would be useful and discuss from time to time. Its one of the feature candidates for the next version of the transfer service in 3.4.   Let's see how priorities shape up.
* I agree that the typical pattern is for all web content to be assembled within alfresco and then deployed out to the web runtimes. It's a good strong pattern. But we do already have senarios where only part of the content is controlled via Alfresco.   And you can also have automatic information feeds into alfresco which is then deployed out. That's another strong pattern.
* In addition to flat files being deployed, Alfresco also allows deployment of content to support a web site.   This could be part of what you were getting at by talking about the "associated database".    With 3.3 we are expecting people to start using Alfresco as a CMIS runtime to support their dynamic websites.
* And finally deployment targets can already execute "predefined commands", so you can deploy a dumpfile to your your database already.

Re: Musing about Alfresco WCM for web app management

bnordgren — Fri, 09 Apr 2010 00:44:48 GMT

I had envisioned "deploying a dumpfile" to mean deploying a dumpfile that was associated with a snapshot in the authoring environment. Hence the predefined command is parameterized by a dumpfile which is not deployed to the filesystem target with the rest of the web app.

However, if the dumpfile were deployed, (and always deployed to a file of the same name), I can see adding the database restore as the postcommit hook.

Meanwhile, I spent the day trying to draw a system diagram (and assemble a toolset) which could accomplish my objectives using off the shelf tools. I think I found something that works. Briefly, the authoring server is in charge of versioning and deploying to test/live targets. Each web project in the authoring server assembles all of the aspects of the target web app into one place using a directory tree to keep things tidy: program files, user generated data/content, database dump, and configuration directories.

I have rsync pulling changes into a "web app mirror" on a nightly basis. The web app mirror has the same form as the web project. Rsync connections are always outbound thru the firewall, and use ssh as a remote shell.

Our web app mirror (on a local machine) is then mirrored to our data center in Kansas City using rsync.

Finally, to get the changes into the Alfresco web project, I've come up with rsync-ing from the web app mirror to a CIFS mounted sandbox. I think I'm going to have to create a dummy user called "mirror" for this, because I don't think Alfresco can use our corporate active directory for CIFS authentication.

Of course, one of the Apps I'm going to treat in this fashion is Alfresco itself, so each app is going to have a "current mirror" in our data center as well as a versioned history in the Alfresco app mirror. Call me paranoid.

I can draw a picture (two pics, actually: one with the authoring server inside the firewall and one with the authoring server outside) if there's any interest. I'm going to have to document this for our website technical people anyway.

In any case, having gone thru this mental exercise and locating an rsync for windows with both the rsync command line binaries and a gui front end, I think it may be best to take a lighthanded approach to gathering user generated data into a web project. By that I mean to delegate the change detection and transport security to external apps which already do that well, and have Alfresco push the buttons on those apps. (Much like the approach taken to connect to the openoffice server).

Sorry I've been so longwinded recently. I get that way when my head's in the middle of a puzzle.

Re: Musing about Alfresco WCM for web app management

bremmington — Fri, 09 Apr 2010 15:59:27 GMT

You're doing some interesting things

Your solution to the two-way sync seems perfectly reasonable. I assume that you're not expecting there to ever be conflicting changes on the authoring and live servers, otherwise it would become more complicated. It is this that would cause the greatest difficulty with regard to the "database dump" idea that you mention in your initial post. How would a two-way sync work in that case? Would the database on the live server be considered the "master"? This would seem to make most sense in the case of Redmine and Joomla!, but perhaps not for Alfresco. I'm not sure how managing and deploying database dump files with Alfresco would fit into most use cases - perhaps you would clarify your thoughts?

As Mark mentioned earlier, the question of UGC is one that is under consideration at Alfresco. It will be something that we will be addressing in the product at some point, but not in a timeframe that would help any current projects.

Re: Musing about Alfresco WCM for web app management

bnordgren — Fri, 16 Apr 2010 16:15:32 GMT

Sorry for the delay. Was implementing a generic cross platform web app replicator using rsync and ssh in python. Still have a bit of work to do on it. Haven't closed the loop back to Alfresco WCM yet.

My thought on "conflicting changes" is that changes are likely to be separable. To illustrate, my "alfresco" web app directory contains:

app/ : Alfresco program files as they exist under the tomcat directory

db/ : Contains a tarball of the dump of the "alfresco" database.

content/ : All the contents of "alf_data"

config/ : Alfresco configuration files under ${catalina.base}/shared/classes

Clearly, one cannot use an Alfresco instance to store a mirror of itself without getting the infinite mirror effect. But an Alfresco WCM instance that is responsible for maintaining the Share deployment, that's doable.

Let's say I create a user (and sandbox) called "mirror" which receives all the changes from the live site. These changes should be localized to the "db" and "content" directories. Now let's say that I'm upgrading to Community 3.3. I use my own account (and sandbox) to update the app and config directories and deploy to a test server. Once I have a working merged copy of "current" db/content with "new" app/config, a final shutdown/update of data/deploy/restart ought to bring the new system online with a minimum of fuss (and a fair degree of certainty that I can back out my changes). The record of what I had to change to make it work is stored in the WCM with no additional effort on my part, and it is easy for future me (installing Community 3.4) to look back to see what I had to change last time.

In this case, I'd use WCM instead of Subversion because the vast bulk of changes will be to zipfiles (which means the entire file will be erased and replaced with every commit). Additionally, I am only interested in keeping backups for a week or so.

Of course, if there are two administrators changing the configs in conflicting ways, they can solve their conflict using the traditional cage match to the death ritual.