Jeff Potts recently announced the general availability of an integration between Drupal and Alfresco. The integration uses CMIS and could potentially connect Drupal to any CMIS compliant repository. While I would call this type of Drupal configuration experimental (that is, don’t try to run The Onion on it), it does show potential. Alfresco’s focus on web content management has been as an extension of internal collaboration (i.e. publishing internal knowledge assets out onto the web). Alfresco doesn’t have a strong vision on pure web publishing or hosting community websites. The front end delivery part of Alfresco is just emerging through its Surf framework. Drupal, conversely, is all about the front end. There is a similar Alfresco integration available for Joomla!, which provides a menu set that reads from an Alfresco repository. This integration also uses CMIS as an interface.
My main hesitation with recommending this configuration (or the Joomla! one for that matter) to my clients right now is that the Alfresco repository is not fast enough to be the runtime behind a high traffic website – certainly not the AVM and probably not the DM either right now. Most Alfresco powered websites publish flat HTML pages or push out the content as XML to be rendered by a de-coupled delivery tier (see deployment patterns). There is an integration that puts OpenCMS in front of Alfresco, but that works by replicating a folder in the repository over to the OpenCMS repository (see my write up here). That seems more scalable from a traffic perspective.
In the near term, I think that the best use for this integration is for customers who use Alfresco for their Intranet and want to publish some of their internally-managed documents out to low-traffic pages on their website (perhaps some PDFs of investor relations documents or job application forms). In the longer term, performance and scalability of the Alfresco repository are expected to improve. Performance is a key focus for the next releases (3.1 and 3.2). In particular, they are building the infrastructure for improved load testing so they can optimize for intensive concurrent access by thousands of users. These improvements will certainly make a fully Alfresco-backed, high traffic Drupal or Joomla! site more viable.
Related posts:
- Redfin on Bricolage There is a good post on the Redfin blog about...
- Alfresco/OpenCms Integration There was a recent announcement on the OpenCms mailing list...
- Nice article benchmarking Joomla! and Drupal I just saw this blog post by Dries, who is...
- Alfresco and E2CM Alfresco has been tearing up the newswire recently with announcements...
- Drupal and Alfresco Jeff Potts has a nice post about how Alfresco and...
Awesome logo!
drupal configuration…
…
Seth, good points, but I don’t know that you have adequate cause for hesitation in recommending Alfresco. You *do* note that it’s the Alfresco+Drupal (and Alfresco+Joomla) integrations that you hesitate to recommend for high-traffic websites, but you say it’s due to the speed of the Alfresco repository.
I might agree except that Alfresco is *already being used* in dozens of high-traffic websites, with exceptional performance. Name the large media company of your choice, and chances are very, very good that Alfresco is the CMS behind their site (I can’t name them all to do confidentiality provisions in our contracts, but Fox, NBC, and Activision are three that are publicly referencable).
While it *is* true to say that we don’t have any high-traffic examples of Alfresco+Drupal/Joomla integrations, saying that our repository isn’t fast enough to handle high-traffic sites is demonstrably incorrect.
What we’re seeing (consistent with your other observations) is that Alfresco is being used as the foundational/backbone CMS for a host of massive websites, while Drupal and Joomla are being used for front-end publishing. My personal hope is that we’ll see those two worlds increasingly come together, as I think both Drupal and Joomla are exceptional systems.
When they do, our performance will be more than adequate to support them. In fact, based on our growing high-traffic customer base, I’m guessing Alfresco will increasingly be the CMS of choice for those looking for a content-services platform upon which to build such sites.
Thanks for the comment Matt. My understanding of the implementations that you mention is that Alfresco publishes to the file system or database of a de-coupled delivery tier. Therefore, the Alfresco repository is not exposed to the intense load of the live site runtime. This is especially true for implementations that use the AVM (Advanced Versioning Model repository that his built into the WCM) which is considerably slower than the standard Alfresco repository that is used by the rest of Alfresco. If I am wrong on this, please let me know. I am very interested in learning about how Alfresco is scaled in this way “out in the wild.”
Hi Seth,
The Alfresco/Drupal integration follows the dynamic page assembly pattern already established by Drupal. This is the “frying” approach (as per your article on CMS deployment patterns). As such, you’d naturally have to build out your Drupal presentation layer with due consideration to content pull throughput.
Even in this case, Alfresco scales quite well.
An out-of-the-box Alfresco installation provides all kinds of rich goodies – from things like full content auditing, access control lists, workflow, versioning, transformation services, persistence validators, metadata extractors and much more. We provide it straight away so that folks don’t have to incur the cost of building it themselves. However, we’ve also been diligent about following standards and adhering to good patterns so that these things can be replaced or removed, depending on the customer’s needs.
Flexibility is key. While we want our customers to be able to get something up and running without much difficulty, our collective experience is that no two customers have exactly the same runtime environments. Alfresco provides a rich set of configuration options and capabilities so that customers can both tune to their specific environments as well as implement their required features. They need to be able to do this with consideration to both horizontal and vertical architecture.
Fundamentally, Alfresco is fully clusterable within the delivery tier. Each node can be individually tuned to adjust the scalability characteristics – this essentially means adjusting the per-request overhead entailed by things like integrated workflow, metadata extraction, versioning, access control lists and the like.
Each customer is a little different – some may want these features on the delivery tier and others may not. For example, a customer with rich UGC requirements may require versioning or ACLs. Conversely, an public website might not wish to have these things. Rather, they may want to utilize aspects to auto-calibrate content affinity.
Alfresco additionally provides a variety of options for fault tolerant and high availability configurations. Alfresco’s services team provides guidance and best practices on how to best design and account for horizontal scale in these delivery environments.
As Matt pointed out, we have many customers who scale quite adeptly on Alfresco. This is precisely because Alfresco provides excellent scale-out of the delivery (web runtime).
For folks interested in scale-out of the web runtime, I’d encourage reading through Seth’s CMS deployment patterns article and then taking a look at Alfresco Web Content Management.
Alfresco Web Content Management plays very strongly to the “structured content” approach as described in the article. Content is modeled once, version controlled, audited, approved and then published out in a multi-channel fashion to deployment receivers. These receivers are rich in capability and provide support for both pre and post-transformations, content handling and callbacks.
This is done in such a way as to continue to remain very flexible. We are able to support a wide variety of Web Runtimes. We offer one out-of-the-box (Alfresco Surf) but we also published straight for consumption by web frameworks powered by PHP, .NET, Java (Seam, Tiles, more), Grails and more.
Alfresco WCM lets you further divide your content between dynamic types and static types. Segmenting your content as such lets you avoid request-time processing for content that can be pre-generated or cached.
These is the kind of flexibility that our customers have asked for – indeed, we have customers who employ all of these technologies and usually in very interesting ways!
Thanks for a good article. I wanted to add that I really like the new web site design. As they say up in Red Sox country, the Alfresco/Drupal logo is wicked cool!
Michael Uzquiano
Alfresco Product Manager (WCM and Network)
Thanks for the explanation MIchael! The post that Michael refers to is CMS Deployment Patterns Am I right to assume that most high traffic sites are using the structured content.
Am I right to assume that most high traffic Alfresco sites are using the structured publishing and published static html models?