Category: Drupal

It’s a CMS! It’s a portal! It’s a community platform!

Screencast: Alfresco-Drupal CMIS Integration Demo

UPDATE: Screencast now lives here:

I’ve created a new screencast that shows the Alfresco-Drupal CMIS integration in action over at Optaros Labs. The screencast shows content moving back-and-forth between Alfresco and Drupal, content being displayed in a Drupal site that lives in Alfresco, and a CMIS CQL query being executed against the Alfresco repository from Drupal.

The Drupal CMIS module and the CMIS Alfresco module are available at Drupal.org.

Alfresco-Drupal integration through CMIS

As I’ve mentioned here and on twitter, we posted our Alfresco-Drupal integration on Drupal.org on Friday. I did a short write-up on it over at Optaros.com that gives the why and the what so I’ll not repeat it here.

We split the integration into two modules: CMIS API has nothing Alfresco-specific–it just knows how to make RESTful CMIS calls to an arbitrary CMIS repository. The Alfresco CMIS module has the Alfresco-specific logic. You need both to make the integration work. If you’ve got Alfresco 3 (Enterprise or Labs) you don’t need to do anything to your Alfresco install to enable the integration because it’s already CMIS compliant.

There is still a lot of work to do on this integration. For example, right now we’re only moving plain text content back-and-forth between Drupal and Alfresco. And we use a “single account” approach so that to Alfresco, every request appears to come from one user instead of passing through the authenticated Drupal credentials. But this is an imporant integration to us so I expect it to evolve substantially in the coming months.

I got good feedback on the recent screencasts I put together for Share (Part 1, Part 2) so if I get some time this week I’ll do one that gives a quick tour of the Drupal integration.

InfoWorld gives Acquia Drupal a spin

Over at InfoWorld, Mike Heck spent a few days playing with Acquia Drupal, Acquia’s commercially-supported Drupal distribution. He also tested out some of the features provided by Acquia Network and threw a couple of test issues at Acquia’s support team. Mike liked what he saw and said he saved a lot of time using Acquia’s distribution instead of having to start with Drupal core and then adding the modules himself, but admitted that his week or so with the product wasn’t enough to truly put the product or the support organization through its paces.

UPDATE: Removed the word “hardened”. Acquia does not change Drupal core.

Acquia Drupal officially launches

Do you love Drupal but wish you could get a “certified” version and commercial support? Now you can. Acquia, the commercial company recently formed by Drupal founder Dries Buytaert and Jay Batson, officially launched Acquia Drupal this week (press release). Acquia Drupal is a commercially-supported distribution of Drupal. It includes Drupal Core plus a handful of essential modules. In addition to the distribution, customers can take advantage of the Acquia Network for things like monitoring, spam blocking, and update notification.

Acquia Drupal and Acquia Network subscriptions are freely-available, even if you don’t pay for support. If you want to try it out, check out the download instructions.

Optaros is very excited about the launch and we look forward to working with the Acquia team. We’ve had success implementing Drupal as a community platform for a number of clients. Having a commercial company behind Drupal is a big step toward broader acceptance among enterprises who can’t or are unwilling to self-support.

Alfresco plus Drupal thoughts

I’ve had several discussions with Optaros clients and internal team members lately around Drupal and Alfresco integration. Particularly around this topic, I usually try to listen more than I talk. I want to make sure I understand where the value is for this kind of integration rather than simply geeking out on yet another “stupid CMS trick”. I thought maybe I’d bounce a summary of these thoughts off of you.

The key is to leverage the strengths of each. If you don’t have a problem that requires this particular combination of strengths, assembling a solution from these two components isn’t going to be of any value at all. What are some of the key strengths relevant to this discussion?

Drupal has:

  • A front-end presentation framework. (I would add that it is written in PHP–a relatively widespread language that’s easy to pick up).
  • A very large library of modules, most of them focused on building community-centric web sites.
  • A lightweight footprint, requiring only a web server, MySQL, and PHP. (Yes, I know it is possible to run Drupal on other databases but not every module will).

Alfresco has:

  • Robust workflow via the embedded JBoss jBPM engine.
  • Smart management of file-based objects (files go on the file system, metadata goes in the database, and an API that abstracts the separation).
  • A plethora of file-based protocols and API’s for getting content into and out of the repository, including a framework to easily expose content and business logic via REST.

Silo’d community solutions are best implemented in Drupal alone. Why complicate your life with a separate repository? It adds no value in that situation. Similarly, straight document management (and even team-based collaboration) really can be addressed with the Alfresco repository and the standard Alfresco web client (or, soon, with Alfresco’s new Share client).

I think where Drupal-Alfresco makes the most sense is in cases where there is a significant amount of file-based content that requires “basic content services” such as workflow, versioning, security, check-in/check-out, but needs to be shared in the context of a community.

Alfresco becomes even more useful when there are multiple communities that need this content because you can start to leverage the “content-as-a-service” idea to make the content available to any number of front-end sites (where those sites might or might not be Drupal-based).

Suppose rather than one community, you have ten. Each community will have community-specific content but there may also be a set of content that needs to be leveraged across many communities. A subset of things you might be concerned about include:

  • Some content might need editorial review and approval before it goes live, but not everything.
  • Not all content comes from internal sources (pushed out from the repository). Some might originate from one of the communities as user-generated content. That content might need editorial review before it is made available on other community sites.
  • Communities need flexibility in how/if they expose cross-community content.
  • Tags and other metadata value need to be consistent between an end point and the repository (and therefore, across all end points).
  • Search needs to be properly scoped (does it include community content only, community plus shared content in the repo, multiple selected communities, or all communities)
  • Some clients may not be able to control the technology used on these community endpoints.

In these scenarios, Alfresco acts as your core repository and Drupal provides the front-end presentation layer. When you look at it this way, Drupal really becomes equivalent (in terms of where it sits in the architecture and the role it plays) to traditional portals like Liferay or JBoss Portal.
Content sitting in Drupal is harder for other systems to get to than when it sits in Alfresco. There are Drupal modules that make it easier to syndicate out but Alfresco’s purpose-built to expose content in this way. Once it is in Alfresco, content can be routed through Alfresco workflows, and then approved to be made available to one or more front-end Drupal sites. Content could come from a Drupal site, get persisted to Alfresco, routed around for editorial review, and then be made available. It really opens up a lot of possibilities.

Not all Drupal modules need to persist their data back to Alfresco. Things like comments and ratings will likely never need to be treated as real content. Instead of trying to persist everything you would either modify select modules to integrate with Alfresco or create new ones that work with Alfresco. For example, you might want to have Drupal stick file uploads in Alfresco instead of the local file system. Or, it might make sense to have a “send to alfresco” button visible to certain roles that would send the current node to Alfresco.

It doesn’t all have to be Drupal getting and posting to Alfresco. There might be cases where you need some Drupal data from within Alfresco. Maybe you are in Alfresco and you want to tag objects using the same set of tags Drupal knows about, for example. Or maybe you want to do a mass import of Drupal objects into the Alfresco repository.

I’ve got a little test module that uses Alfresco’s REST API (including the new CMIS URLs) to retrieve content from Alfresco and show it in a Drupal block. I can talk about it in a separate post.

Drupal-Alfresco Integration and Alfresco’s Move to the Front-End

Via Dries Buytaert, Rob Purdie is announcing the relaunch of Amnesty International‘s site. The new site was built using Drupal and Alfresco.

It is interesting to see how many people have commented on both posts who are craving more information about Drupal and Alfresco integration and it is no wonder. As I mentioned last year in this post, Optaros sees the two offerings as highly complementary–they aren’t (yet) competitors.

We do a lot of implementations in both Drupal and Alfresco. We think PHP plus Alfresco, or in this case, Drupal plus Alfresco is a great combination. Why? Using PHP and Alfresco together is the best-of-both-worlds: You get the speed of development that PHP brings plus the strength of an
open, enterprise repository on the back-end. In Drupal’s case, specifically, add to that the
availability of thousands of pre-built modules as well as a true site (presentation) framework which is something Alfresco currently lacks (more on that in a second). The interface between the two is best facilitated by Alfresco’s REST-based web script framework which is itself based on lightweight coding tools (JavaScript and FreeMarker).

If you’ve been following this blog and the Alfresco Community Conferences, you know that Alfresco is making a move to the front-end. Clearly, Alfresco sees the lack of a Drupal-like front-end as a short-coming, and they are working hard to address this in their coming releases. Here are examples of what’s coming down the pike that may ultimately position Alfresco more directly against Drupal in the future:

  • Web scripts are being split out from the repository process. In the Community head it is now possible to run web scripts in a process separate from that of the core Alfresco repository process. And web scripts running in that standalone process can remotely invoke web scripts running in the Alfresco repository, even if the two are running on separate physical hosts. This will likely form the foundation of Alfresco’s dynamic web site approach: Web scripts running outside of the context of Alfresco, in a plain old servlet container, say, can take advantage of the web script framework, even if they never make a single call to Alfresco.
  • Alfresco is building a WYSIWYG, browser-based site builder tool. The Alfresco Dynamic Website (ADW) will allow you to assemble web sites and web pages by selecting modules (built with web scripts) from a module library and arranging them on the page.
  • Alfresco is moving their web clients from JSF to web script-based web sites. The new Alfresco client will be based on web scripts with the eventual goal being to build it and manage it as if it were any other normal, dynamic web site. The client will be a reference site which you can use to build your own dynamic sites.
  • Alfresco is trying to generate developer excitement around web scripts. Alfresco’s push in the developer community to get people excited about web scripts is no coincidence. If they can get the community to help develop a compelling library of web script-based modules, and if they can create a productive front-end development framework that can plug in those modules, Alfresco will be much more attractive to clients who benefit from a front-end presentation framework and pre-built components than it is today.
  • Alfresco is marketing heavily around community and Enterprise 2.0. As you may have seen at the Community Conference and other Meet-ups, Alfresco is driving towards more community, social networking, and general “Enterprise 2.0” features and functionality. This is usually mentioned in the context of being a Sharepoint Killer but it could also mean a blurring of the differences between Drupal and Alfresco as well.

I’m not saying that when the 3.0 release of Alfresco comes out it is going to be on par with Drupal. But I do think it is interesting to watch what’s happening as Drupal and PHP solutions look for more robust back-ends while Alfresco moves toward better front-end site development and module frameworks.

Two worlds collide in Boston

Okay, so maybe it wasn’t so much a collision as it was a harmless grazing. Even though there wasn’t a lot of crossover between the two, I’d still like to offer, as Mel Brooks put it, a “firm embrace” to whomever had the bright idea to co-locate DrupalCon with AIIM this week in Boston because I think (I hope) it gave the old guard of ECM some exposure to and appreciation for the wave of innovation taking place in the space.

Unfortunately, I don’t think there was as much crossover from the AIIM attendee side as there was from the Drupal side. There were a few curious DrupalCon’ers that ventured in to the AIIM exhibition hall. One person shouted out, “Hell yeah, Open Source!” as she walked by the Alfresco/Optaros booth, giving me a sort of “fight the power” gesture as she passed (at least that’s how I interpreted the gesture). Others stopped to chat at our little oasis of open source in the closed source desert. The serious under-representation of open source at the AIIM conference was a major topic of conversation.

I doubt we’ll ever see full integration between the two conferences–90% of the DrupalCon attendees were technical developers and integrators while AIIM attendees are mostly IT and business people evaluating or looking to purchase ECM solutions.

Another big difference is scope. AIIM, as an organization and as a conference, has gotten way too broad, at least for my own interests. A scanner that knows how to open sealed envelopes before imaging the contents is really cool, it’s just not a typical component of the solutions I implement.

Forgive the tangent, but this problem goes beyond AIIM to “ECM” itself. As Alan Pelz-Sharpe of CMSWatch pointed out in one of his sessions (the CMSWatch sessions were far and away the best sessions), almost everything under the sun calls itself “ECM” from source code control to imaging to records management in addition to my focus areas, WCM, Portal, Search, Collaboration, and Document Management. Indeed, the term was invented, largely by vendors, as a way to group all of those types of solutions together in an attempt to convince buyers that having one vendor that could do all of those things is better than buying from individual niche vendors.

I don’t deny a need for an association or a conference that can help people solve problems in these areas but how much overlap can there really be between people interested in microfiche and those looking to implement Web 2.0? One of our clients in the media industry stopped by the booth and asked me, “Are you sure this is the biggest content management conference of the year?”. He was having trouble finding the relevant content management information lost in the noise of vendors hawking copiers, scanners, and printers.

Anyway, back to the “two worlds” topic, the idealist in me hopes a sort of ping pong diplomacy took place. Perhaps the DrupalCon attendees were the New York Philharmonic to AIIM’s North Korea. Maybe a few of the suits learned something from the insightful questions being asked by the messenger bag crowd. Rather than be annoyed, I was actually encouraged by the legacy ECM vendor who came to our booth and grilled me on Alfresco and how it compared to their product. I tried to get her to renounce her faith right then and there but she was tough.

AIIM could do more to encourage that kind of cultural exchange and maybe even foster the innovation that old school ECM so sorely lacks. It sounds like the Rocky Mountain Chapter is planning on offering some open source topics soon. That’s great and I hope to see that happen in other chapters. And while we’re at it, maybe AIIM could offer free floor space to non-commercial open source projects. Just a thought.

At the very least, I hope the physical presence of 800 – 900 people passionate about open source content management was a jarring reality check to AIIM, legacy ECM vendors, and the larger community.

On a tactical note, a nice side-benefit of the co-located conferences was that the Optaros folks attending DrupalCon were able to put in some booth time on the AIIM show floor. If you want to read more about some of the DrupalCon sessions, check out John Eckman’s blog.