Highlights from the Alfresco Meetup in Chicago

Other than the drenching I received between the blue line and the hotel (both coming and going) I thoroughly enjoyed my time in Chicago with the Alfresco crew last week. I ran into some Optaros customers, past colleagues, blog and book readers, and even some consultants from another firm who told me they came across some code I wrote for a client many years ago that they now support. (It was a custom Documentum WDK app for a certain carbonated beverage company that was actually pretty cool at the time, but I’d love to re-do it on an open stack).

The day was well-spent with Matt Asay kicking off with a state of the union, of sorts, followed by a couple of sessions from Michael Uzquiano, Alfresco product manager. I thought Uzi’s discourse on the macro- and micro-economic climate was interesting, but a bit arduous. Yes, we’re in some tough times and that’s good for open source. Check. Next slide. My favorite part of his talks were on the Alfresco roadmap (see Highlights, below).

Ed Wentworth, from Orbitz, gave a cool talk on how they’re using Alfresco. Ed’s team is implementing what I think is a best practice pattern: Services-Oriented Content Management. Orbitz has a lot of dynamic sites built on content chunks, not complete, fully-baked pages. So they leverage Alfresco’s strengths as a core repository, and then expose the repository as a service to the front-end (and to other services). They use the web client only for atypical or administrative interactions, and custom Share components and Surf apps for content authoring.

Orbitz also leverages an “Enterprise Content Bus” comprised of a ServiceMix ESB, BPM, and a rules engine (more info on ECB here and here). The ECB is primarily focused on orchestrating content-centric processes like content routing and delivery. Not everyone is going to need an ECB but if you’ve got anything that resembles a content production pipeline, it can really make your processes much more flexible with less code.

TSG did a cool demo on an open source solution for annotating attachments (screencast). It looks like it is still in dev mode but it’s got a great start and hopefully they’ll continue to enhance this and make it available to the community.

I did the Alfresco-Drupal CMIS integration demo (screencast) which seemed to go over well. Most people in the room acknowledged that they have more than one CMS, so there was interest something that could enable multiple web sites talking to one or more back-end CMS repositories using a standard API (CMIS).

At the end of the day a sort of “Everything you wanted to know about Alfresco but were afraid to ask” roundtable formed which was cool. I tried to demo the Alfresco-Django integration we’ve been working on. It worked on the plane and works now, but the demo gods chose that very day to expire my Alfresco license, and although hard to miss, I didn’t notice that as the root of my problem until after the meeting. It’s all good now so if you’ll be at the San Francisco event next week and want to see Django and Alfresco working together, let me know.

Highlights of the Alfresco Talks

  • Alfresco now has 1000 paying customers. Matt says it took Documentum many years to get to that point. With the price disparity, obviously, Alfresco needs many more customers than Documentum to thrive, but still, that’s quite an achievement.
  • There’s a Groovy renderer coming to Surf after 3.2.
  • Speaking of Surf, I’m not sure when it is coming, but Spring WebFlow is now being integrated into Surf which is much-needed.
  • If you’re looking for CMIS resources, CMISDev.org is a new site aimed at pulling a lot of that stuff together.
  • 3.2 Labs targeted for June
  • 3.2 Enterprise targeted for September 2009
  • 3.3 Labs/Enterprise targeted for 1Q 2010
  • 4.0 Labs/Enterprise targeted for 2nd half of 2010

The 3.2 release is shaping up to be pretty major. Here are some of the things planned for 3.2 that caught my ear:

Surf Mobile. This is an addition to the Surf framework that makes it easier to develop Surf apps that work well on the iPhone, although audience members said the demo site was also usable on their Blackberries.

New Form Service. Today you’ve got “property sheets” in the Explorer client which are driven by the content model and the web-client configuration XML, web forms in WCM which are defined using XSD, and custom forms in Surf which aren’t defined using any kind of framework at all. The new form service will provide a single form definition/presentation framework across the entire Alfresco platform. It’s a Good Thing.

IMAP integration. This allows you to use your Outlook client (and Thunderbird and whatever else you use that knows IMAP) to get things into and out of the repository. One use for this is to archive email by dragging-and-dropping mail into mail folders which are backed by Alfresco. Another is to easily snag content from the repo without leaving the mail client. I don’t know if it will be in there, but a great feature would be to allow me to drag-and-drop a piece of Alfresco content onto my message which would then get translated into the download URL rather than a file attachment.

Clustering. Several attendees fell to the ground and wept, overcome with emotion, when Uzi said 3.2 would support real clustering of both the DM and WCM repositories. Clustering is something that has bedeviled complex Alfresco implementations. I’ll maintain my composure until I see this actually working.

Index refactoring. Ever do a search that fails to return a piece of content you know is in the repo? Or, the other way, when you see something that you know was deleted? Do you mark the time it takes to reindex your repository (to fix index inconsistencies) by how many times the moon rises and sets? I have no idea whether any of these issues will get better in 3.2 but hearing “index” and “refactor” in the same sentence makes me hopeful.

All-in-all I’d say it was one of the better Alfresco-led meetups. I’m looking forward to reconnecting with many of you next week in San Francisco. I’ll see you there.

3 comments

  1. Justin Luzier says:

    Very happy to hear about the ‘index refactoring’ in 3.2. It’s a very weak link in Alfresco right now, and I have seen what you describe in a production setting (i.e. Lucene thinks it has something that Alfresco does not, which is screwing up webscript calls). If anything, I’d like to see more tools related to Lucene index maint. in Alfresco; restarting and re-indexing is not a solution most production customers can live with given the long index times, etc.

  2. Jean Barmash says:

    Justin,

    Not sure if you are an Enterprise customer or not, but in 3.1, as an Enterprise Only Feature, a new UI (set of web scripts) was added to do much more sophisticated index management, including partial re-indexing, diagnosis, etc.

    It’s not something we recommend you use without guidance from support, but just wanted to make sure you know that we have in fact been working on such tools, in addition to a larger refactoring effort that Jeff mentioned.

  3. I want to thank you for your openess, Jeff. You are an authority on Alfresco, and your words should have a serious impact on Alfresco engineering, as you speak out what many have suffered from.

    Jean: good to hear. Lucene is a timebomb ticking under Alfresco. Current ECM repositories will grow, exhibit frequent delete and creations of content, and encounter index inconsistencies, leading to downtimes of many days. I lived one this week. It’s easily replicated: just sync with a larger LDAP directory (with a few 1000 users and groups): Alfresco creates and deletes the whole bunch at every sync pass, leading to an rapid increases in useless transactions in alf_transactions.

    Alfresco must asap get rid of a full-text indexing engine to index the structured data, and use lucene for what it is meant (full text indexing). indexes are in the database. Should be used. The current trade-off of flexibility in the datamodel and database portability versus structured query performance and reliability is a basic design flaw. Alfresco is allowed to make a few, as so many wonderful choices have been made. But not repairing it is exposing partners and customers to a major risk.

    To finish off: I believe a system is scalable to the extent it can be repaired off-business hours, after an incident in production, to be operational again the next morning without data-loss. For Alfresco that means: a few million documents, with not too much meta-data. Given that the -auto option of re-indexing works.

Comments are closed.