People new to Alfresco are often unaware of the existence of two different repository implementations within the product. One, which I’ll call the “DM Store”, is the classic store, the one that’s been used by Alfresco since the beginning. The other, the “WCM Store” or, as it is often referred to in API-speak, the “AVM Store”, was born with the addition of the Alfresco WCM product offering. Whether you are doing document management or web content management, you use the same Explorer client, but under the covers, your content lives in two very different types of repositories.
The Alfresco story on why a second repository implementation was created is that the Engineers writing WCM didn’t believe the DM store was capable of providing the kind of support for versioning, branching, and layering functionality they needed (hence, the AVM acronym, which stands for Advanced Versioning Manager) so they created an entirely new repository implementation to support WCM.
Why does this matter, apart from being a possible topic of conversation at your next get-together (“Healthcare is easy to fix. Do you think Alfresco will ever unify their two repository implementations?”)? It matters because the “two sides” of Alfresco are not equivalent in terms of functionality and depending on what you need to do, you may find yourself performing unnatural acts to work around the disparity.
Many projects will be completely unaffected by the differences between Alfresco DM and Alfresco WCM. But it is important to know what these differences are when you first begin to plan your solution to avoid uncomfortable conversations between you and your customer when you realize you’ve made a bad assumption.
I’ll assume you know the high-level capabilities of both Alfresco DM and Alfresco WCM. Obviously there are some things one product can do that the other can’t that are by design (sandboxes and virtualization in WCM, for example). What’s more important to understand are the subtle (and sometimes not-so subtle) differences between the two. Here’s the list and a table that summarizes, if you are into the whole brevity thing:
Content Modeling. Alfresco DM uses a proprietary XML-based description of the content model while Alfresco WCM uses XML Schema. On the surface this isn’t a big deal, but it does mean if your repository contains a mix of DM- and WCM-stored data, you won’t have a single model that defines it all and you could possibly have duplication between the two.
Custom Content Types. In Alfresco DM, when you create content, you tell Alfresco what its content type is. If you’ve extended the out-of-the-box model, you can have any number of business-specific content types with your own custom metadata. In Alfresco WCM, custom content types are not supported. In WCM, your content type is your web form. Interestingly, although the “Type” dropdown is shown in the “Create Web Content” dialog, and it will contain custom content types you’ve defined using the Alfresco DM model, your selection will not be honored. All AVM content is created as an instance of the “avmplaincontent” content type no matter what you select. However, although you must do it through an API call, you can apply custom aspects to AVM content.
User Interface Configuration. Alfresco DM uses a proprietary XML-based configuration file to define the “property sheets” that display metadata in the Alfresco Explorer client for a given content type or aspect. Alfresco WCM uses the embedded Chiba XForms engine to inspect the XML Schema (XSD) and automatically create a web form that will produce data that conforms to the XSD. XSD annotations can be used to influence the presentation of the form fields. One outcome of this is that it is much easier to localize things like property labels in Alfresco DM than it is in Alfresco WCM.
User Interface Extension. If you need to change how the Alfresco Explorer client behaves, there are some things you can do through XML, but advanced customizations will require JavaServer Faces (JSF) development. Alfresco DM and WCM both use the same Explorer client so this applies to both (See “Alfresco User Interface: What are my options?”). However, if you need to change how the web form engine works, you may need to write new Chiba XForms widgets. For instance, Optaros developed a web form used to describe points and regions on Google Maps. That kind of thing requires you to understand how to extend Chiba.
Structured (XML) data entry. Data entered in an Alfresco WCM web form is saved as XML that conforms to the XSD you’ve defined. There is no similar facility for capturing data as XML available within Alfresco DM. At one point the Community code line had “ECM Forms” which was essentially WCM web forms for the DM side of the house, but that’s disappeared in the latest Community release. On the DM side, when you edit metadata you are editing object properties whose values get stored in the database, not as XML.
Transformations. You can use either Freemarker or XSLT to transform Alfresco web form XML into other formats. That transformation is defined as part of the web form configuration which you do within the Explorer client. In Alfresco DM, transformations are more about binary file transformations (DOC to PDF or GIF to PNG, for example). If you want to do Freemarker or XSLT transformations on XML content stored in Alfresco DM, you’ll need to write that yourself (an Action would do the trick). If you want to do DM-style transformations on binary files in Alfresco WCM, that’s not out-of-the-box. You’ll have to do that using the API.
Rule actions. Alfresco DM allows you to configure rules on folders to trigger actions (out-of-the-box or custom) to operate against newly-added, updated, or deleted documents. Alfresco WCM does not support rule actions at all.
Auditing. Alfresco DM has a granular auditing sub-system. You can configure it to audit just about anything you want. Anything except WCM. You can audit web project creation, but not changes to individual web assets within a web project. At least not out-of-the-box.
Object-level permissions. In Alfresco DM you can assign users and groups to roles at the folder and file level. In Alfresco WCM, the UI will only let you go as low as the web project level. The API supports more granular security but you have to implement that yourself with custom code.
Search. Everything in Alfresco DM is full-text indexed and searchable. In Alfresco WCM, only the Staging Sandbox of each web project is indexed. You can do a search from your user sandbox but you’re really searching the Staging Sandbox. If you have any content you’ve created in your user sandbox that you have not yet committed to Staging, web project search won’t find it. Another limitation is that you cannot search across web projects. That search box that’s visible in the far upper right-hand corner of the Alfresco Explorer client is the Alfresco DM search–it won’t find anything in any of your web projects.
Advanced Workflow. Alfresco DM and Alfresco WCM use the same JBoss jBPM workflow engine so there’s no functional difference between what you can do with workflow on either side. The only catch is that in Alfresco DM, all deployed workflows show up in the “Start Advanced Workflow” dialog whereas in WCM, you have to tell Alfresco which deployed workflows are okay to use for WCM. That’s covered in the Alfresco Developer Guide and on the wiki.
File protocols. CIFS and FTP are the only two file protocols supported by both Alfresco DM and Alfresco WCM. Similar protocols supported by Alfresco DM such as WebDAV, inbound SMTP, and IMAP, are not supported by Alfresco WCM.
Deployment. Some people use Alfresco DM to manage content that is published to the web because they don’t need the additional features WCM offers, or they have some other reason to export content to another server. Unfortunately, Alfresco DM does not yet offer a deployment component like the one in Alfresco WCM. If you want to export content from Alfresco DM to some other destination in a systematic way, you’ll have to roll your own solution.
As John and Paul said, “It’s getting better”
Some of these differences will become less drastic in coming releases. For example, Alfresco is implementing a new form service that will be used to define the content model and user interface across the entire product line, so that helps. The WCM deployment functionality is also being refactored and will ultimately work for both DM and WCM. And at every community event Alfresco talks about “repository unification” as a goal for the future, although the timeline is lightyears away in terms of software releases.
As I said, depending on what you’re doing these differences may not affect you at all. Just make sure you don’t assume that a given feature is available everywhere, and make sure you’ve made a conscious decision about what content to put in which repository (DM or WCM) based on your requirements.
Nice post!
One minor nit-pick: it’s not entirely accurate to say “In Alfresco WCM, custom content types are not supported.”- the next sentence is in fact a more accurate summary: “In WCM, your content type is your web form.”.
Perhaps a statement like “In Alfresco WCM, DM-style metadata types are not supported, and are instead supplanted by XML Schema-backed content types (Web Forms).” would be clearer?
Can you please give me a hint, how I can find out if a document has been stored in DM or WCM.
Or does it depend on the content type – so if I use inline HTML or text content, is then WCM used and for uploading a PDF for instance DM?
So if you want DM + WCM you only need Alfresco WCM ? What about mixing both ?
What about commercial opensource pricing ? Is it the same for each product ?
Regards
Peter,
Thanks. What I meant by “custom content types are not supported” is that custom types, as defined in your Alfresco DM model, are not supported. Using your web forms as content types only works for web form content, not other types of files you might manage as part of your web site, so they aren’t “true” content types, in my opinion.
People new to Alfresco might make the easy mistake of assuming that the “DM model” is universal, especially given the presence of a type dropdown in the WCM UI.
Jeff
Martin,
Luckily it isn’t as complex as that. If you are creating content within a web project folder the content is being stored in the WCM store. If you are creating content anywhere else your content is not being stored in the WCM store.
Jeff
Jean-Philippe,
Alfresco WCM is an add-on to the core Alfresco product. It adds the ability to have “web project” folders, sandboxes, preview/virtualization, web forms, and deployment.
Some people choose to manage web content without Alfresco WCM. They use the Alfresco DM store for everything. Obviously, they don’t get to leverage the functionality Alfresco WCM brings to the table when they go that route, but sometimes that’s okay.
You can use the core Alfresco repository to do just about anything. The Alfresco WCM add-on should only be used for WCM use cases. I would never recommend that you try to implement typical document management uses cases solely with Alfresco WCM.
If you have both DM and WCM needs, yes, you can use one Alfresco implementation to do both. One of the nice things about Alfresco is their simple support subscription model–I’m pretty sure one support subscription gets you both DM and WCM, but I don’t work for Alfresco and Optaros is not a reseller, so I’ll defer to Alfresco on the details.
Jeff
Hi Jeff,
I would like start to give you congratulations by your great book and articles, your write it’s very clear and simple.
I have a question about versioning, by default the alfresco doesn’t keep versioning of the properties created in the custom model.
I have created a set of actions to create my own versioning of the properties, but that doesn’t seem to be the better solutions.
It’s possible to configure alfresco to keep property versioning? It’s very strange alfresco doesn’t support it. I haven’t seen nothing about this.
regards
Keep the good work…
Thanks for this article, it is very helpful. I wonder, could it be possible to get an updated version of this since there have been many changes to the repositories in the last year (like virtualization server deprecation). And just to clarify some of the bigger picture if you could. For example, through versions of documentation and various sales pitches, somewhere along the line I got the idea that Share is the WCM. I wasn’t even aware the AVM was the same thing as the “Web Project” WCM. The new Share Web Quick Start is often labeled as a WCM example as if it weren’t confusing enough. I would greatly appreciate your explanation of it all.
Thanks
And yes, keep up the good work!
Jeff,
Great information. Please provide a updated comparison with respect to WCM 3.3+ on all presented features and any new ones.
@tmath, @Apickard,
Honestly, if updated, the chart would be nearly identical for the latest release when comparing Alfresco DM with Alfresco’s AVM-based WCM. The most significant change is that the DM repo now has a deployment solution, albeit a partial one, that can move nodes between Alfresco DM repositories. It is called the Transfer Service.
Bringing Web Quick Start into the mix, I would add a third column to the chart that is basically a duplicate of the Alfresco DM column. But for forms, Quick Start uses Alfresco’s form service. And, for UI customizations, it is all Surf because the UI for Web Quick Start is Alfresco Share. I’m planning to write a longer post on Web Quick Start but essentially, you leverage Alfresco Share as your administrative UI to manage files and content, and then a Spring Surf app to dynamically render that content into user-facing pages. Quick Start provides a starter Spring Surf app so that you don’t have to code it from scratch.
Hope that helps,
Jeff
Thanks you for the quick response, Jeff. This helps a lot. We’re trying to build out a Intranet solution with WCM 3.3 in a decentralized content management model. (We’re not using quick start, but did build a surf framework.) So in our case, each department manages it’s own content. I wonder if it’s possible to assign custom roles/permissions via the api on folders within the web project so that only the respective department content contributor(s)/reviewer(s) can create/update their content in that folder. Ex: HR contributors only update content in the HR related folders, Marketing only has access to their folders within the same web project etc. Furthermore, we want to provide unique multi-step workflows (author->reviewer->publisher) for each department to approve/publish a piece of content in their respective folders. (The content types, “Article” etc, would be shared across all users with in the web project.) In our scenario, we may end up with 100s of contributors, editors, publishers. In short, I was wondering which is a better solutions for what we’re trying to accomplish, the Alfresco 3.3 DM or WCM. Would love to hear your expert input. Fantastic job with your blog and I really enjoyed your book. Will gladly buy it if there is a new edition in the works. 🙂
Alfresco strongly recommends against using the API to set permissions on AVM folders. The rumor is that the code that is in there that theoretically allows you to do that was supposed to be removed because it is broken, but never was removed due to time constraints. So I definitely would not rely on it. Maybe you can have a web folder for each department?
Next, the fact that you have hundreds of content managers is another warning sign against AVM-based WCM. Maybe this is less of an issue if you avoid the virtualization server, but still, I haven’t heard too many success stories from people using AVM-based WCM with that many sandboxes. If there are, maybe someone will chime in.
Workflow is going to be a wash–both DM and AVM use JBoss jBPM which is certainly capable of multi-step workflows, and you could have unique workflow process definitions per department or you could have smarter workflows to reduce the number of unique definitions that are needed. One thing to be aware of is that everyone sees (and potentially selects from a list of) all deployed workflows.
My general approach is to start with a DM-based WCM implementation and then only go down the AVM route when there is absolutely no other way to do what you’re trying to do.
Thanks for reading the book! I’m glad you enjoyed it. Good luck with your project and be sure to let us all know how it turns out.
Jeff
First of all, thanks for replying at 12:30 in the morning. Secondly, it’s great to have such insight.
I’m was planning to use a web project per department at this time so we can apply more focused access control. So we will have 1…n web projects. Do you know if there is any constraints/limits placed on Alfresco for the number of Web Projects created within the system? I hadn’t heard of any.
I’m thinking of a few other challenges as well:
1) Previewing content (user sandbox versus staging sandbox) Is it better to use Virtualised Content Retrieval versus Virtualisation Server? I’m hesitant to use the Virtualization server since it’s set to be deprecated from 3.2+.
2) As you mentioned earlier, searching the user store within web projects and also across multiple Web Projects from the client is a major limitation. I’ll probably have to write a custom dashlet with a webscript over Lucene to aggregate content from the multiple stores as well as for the user store.
3) Sharing of content between the web projects…For example, globally available images or content that’s applicable in multiple sections of the larger site. I’ll need to dig into that as well as see if that’s possible.
DM seems to be so much more matured in some key areas. Although a WCM implementation with multiple web projects seems to better meet our timelines. Will let you know how it goes. Would love to hear your thoughts on the items above and as always is greatly appreciated. Thanks once again, you’ve been extremely helpful.
Quick correction. On item 2, I meant the multiple staging sandboxes, please ignore the user sandboxes search since it’s not indexed.