Category: Portal

Thoughts on portal solutions.

November 5, 2009

Django + Alfresco was a winning combination for retailer’s intranet

Last week I spent some time with one of our clients talking about what it’s been like to live with their Intranet platform based on Django and Alfresco. The conversation got me really excited about what they’ve been able to do since the original implementation and where they are heading.

The client is a well-known, high-end retailer based in Dallas. About a year ago they engaged Optaros to replatform their intranet from a legacy Java portal product to something more agile. They had seen Alfresco and liked it as a core repository, but needed something for the presentation tier (See “Alfresco User Interface: What are my options?“).

The Optaros team worked with the client to consider many options, including open source Java portal servers. The client felt like they needed something lighter and more flexible than a portal server. They were willing to do a lot of the presentation work themselves in exchange for complete design freedom and yet still be enough of a framework to be highly productive. The winning solution turned out to be Django.

Python? No problem.

I was initially worried that introducing a Python-based framework into a Java shop was going to be a problem but they weren’t married to Java. Our team got them up-to-speed quickly and they never looked back. It also helped that the client’s intranet sites were very communication-centric which matched up well with Django’s newspaper heritage.

Here’s how they use the solution in a nutshell:

Content owners use Alfresco Explorer to upload HTML chunks, office documents, and images, set metadata, and submit content for review. This triggers any number of rules that automatically process the changed content (e.g., creating thumbnails, extracting metadata, converting images to a consistent type, creating PDFs from office documents).
Content owners and reviewers can use Alfresco’s “custom views” to preview the content chunk in the context of the front-end site.
Site designers lay out site pages and create components using the Django template system, CSS, JQuery, and other front-end libraries.
Content publishers use the Django administration UI to map areas on the site to categories, folders, and objects in the Alfresco repository–Alfresco has no idea where or how the chunks are being used. This means the repository tier is truly decoupled from the presentation tier, allowing the client to reuse content across multiple areas of the site and across multiple sites within the enterprise.
Designers leverage a Django tag library to create dynamic areas of a page (e.g., when the page is rendered, retrieve all of the content chunks in this particular category from the repository). Django calls Alfresco web scripts to get and post data. The web scripts respond with serialized Django XML which Django caches and then deserializes into Django objects that the front-end can work with.

Separate concerns, play to strengths

The thing to notice about the Alfresco piece is how it sticks to core Alfresco capabilities: Metadata, rules, search, basic workflows, transformers/extractors, presentation templates, web scripts, DM repository. This is straight out of the Alfresco best practices playbook and aligns the client well with Alfresco product direction. A nice enhancement would be to refactor the Django-Alfresco integration to use CMIS which is something we are considering for the open source version of the integration (Screencast, Code).

Agile intranet, happy team

Since the initial rollout, the client has been able to make changes and roll out new sites quickly and easily thanks to the productivity inherent in the Django framework and the clean separation between the front-end app and the repository. Unexpected benefits the client mentioned were how fast they can add new features to the administrative UI (a core admin UI gets built for you automatically by Django) and the ease with which the development team can stand up a new environment.

The language the client team used to describe their work since the rollout summed it up best. They were using words like “beautiful” and “a real pleasure to work with”. When was the last time you heard those sentiments expressed about a WCM implementation?

October 1, 2009

Can GateIn, the new JBoss Portal/eXo Portal combination, outshine Liferay?

I know I’m way behind on this. I’m kind of surprised at how little attention it has received. Maybe I need to refresh my portal-based news feeds. In any case, earlier this Summer, JBoss and eXo announced they would be combining the JBoss Portlet Container with eXo Portal to create a new project called GateIn. Other than the similarity between the concepts “portal” and “gate” I’m not sure what they are going for with the name, but don’t let that throw you off. To get an idea of what it’s about, check out the demo.

Most of our clients looking for open source Java portals have been interested in either JBoss Portal or Liferay. In choosing between the two, one consideration was that, historically, JBoss Portal has been less about out-of-the-box portlets and flashy UI and more about providing a presentation framework. Clients developing solutions that were really 100% custom apps with a portal-like interface leaned toward JBoss Portal (especially if they were already a JBoss shop). Clients looking for more of an “instant community” with ease-of-use on the configuration side and a large number of out-of-the-box portlets leaned more toward Liferay. GateIn appears to be a big step forward for JBoss Portal in terms of the user experience for portal administration and makes JBoss Portal about more than just a framework for presentation services.

Beyond requiring a great user experience for both end users (site consumers) and portal administrators (content managers), portals must also have a fast and intuitive development model. I think this is especially true lately as lighter-weight presentation frameworks have become more popular. As the difference in capabilities between portal and non-portal presentation frameworks becomes less and less, portals can’t afford to offer a soul-sucking development experience.

I haven’t spent any time customizing GateIn so I can’t comment on the developer experience. What I do know is that when you move from developing code using lightweight frameworks like Drupal or Django to Java portal servers like Liferay, you feel the increased complexity immediately. Anti-Java-ites will say that a lot of the complexity in the development experience is there because it’s Java and it will always be that way. I don’t think that’s true–look at frameworks like Grails and Wicket.

The point is, for GateIn to be a serious challenger to Liferay, they’ll need to provide not only the eye candy on the front-end, but also a developer experience that approaches the productivity level we can get with non-portal frameworks. If they can do that, they have a chance against Liferay. Of course even if they manage to do that, they are still up against the “Do we really need a portal server to do this?” undercurrent that threatens both projects. But that’s another blog post.

August 31, 2009

Review: Liferay Portal 5.2 Systems Development, by Jonas X. Yuan

I’ve just finished Jonas X. Yuan’s book, Liferay Portal 5.2 Systems Development and I thought I’d share a few thoughts.

First, I should probably get this out of the way: Jonas works for Cignex, which, from time to time, competes for business with my firm, Optaros. Okay, back to the book…

My overall impression of this book is that it essentially documents the work Jonas and his team did for one of their clients. While it is great that their project was broad enough to generate enough material to be compiled into a book, I felt like I was reading “here’s what we did on our project” instead of “let me teach you how to do Liferay development”.

When I read a technical book, I like to read about concepts and how I might apply those in different situations, and then dive into a realistic application of that concept. This book definitely covers realistic examples–the screenshots are lifted right out of the solution Jonas and his team built for their client. And I like that the example is fairly consistent throughout the book. But I found it very light on context and concepts. That left me feeling a bit disoriented as Jonas jumped from detail to detail with very little being done to set the scene. A simple explanation of “Why are we doing this?” would have been a big help.

Another thing that made this a tough read for me is that there are many grammatical issues with the text. If this were in one or two places, you could rightly accuse me of being a hard-grading Grandson of an English teacher (which I am). Unfortunately the problem isn’t limited to one or two places–there’s one on nearly every page. I don’t blame Jonas for this, I blame the editor. Is the pressure to publish on schedule so great that there is no time to perform even rudimentary grammar checks for things like missing articles?

If you can get past the style, there are good takeaways in the book. You’ll learn:

The difference between building customizations in ext versus plugins
How to use ServiceBuilder
How to build portlets using Struts and Tiles
How to extend the Journal CMS with structures and templates
How to build and customize themes and layout templates

There’s a chapter on Liferay’s Social Office and how it works behind the scenes, including details on Inter-Portlet Communication. Jonas has also included a chapter on moving content between multiple environments (Staging/Production) which is an area where portals are often less than optimal.

There is a lot of code included in the book and available for download. Several of the code snippets in the book need to be debugged before they will run properly, but most are easily worked through. The book suggests working with the Liferay source from HEAD, but I had to use the 5.2.3 tag to get the ServiceBuilder stuff to work correctly.

While this book isn’t for everyone, I’m glad Jonas wrote it. Liferay is a complex piece of software and the community needs all the documentation help it can get.

April 20, 2009

Alfresco User Interface: What are my options?

People often need to build a custom user interface on top of the Alfresco repository and I see a lot of people asking general questions about how to do it. There are lots of options to consider. Here are four options for creating a user interface on top of Alfresco, at a high level:

Option 1: Use your favorite programming language and/or framework to talk to Alfresco via REST or Web Services. PHP? Python? Java? Flex? Whatever, it’s up to you. The REST API is nice because if you can’t find a URL that does what you need it to out-of-the-box, you can always roll-your-own with the web script framework. This option offers the most flexibility and creative freedom, but of course you might end up building constructs or components that you may have gotten “for free” from a higher-level framework. Optaros‘ streamlined web client, DoCASU, built on Ext-JS, is one freely-available example of a custom UI on top of Alfresco but there are others.

Option 2: Use Alfresco’s Surf framework. Alfresco’s Surf framework is just that–it’s a framework. Don’t confuse it with Alfresco Share which is a team-centric collaboration client built on top of Surf. And, don’t assume that just because a piece of functionality is in Share it is available to you in the lower-level Surf framework. You may have to do some extra work to get some of the cool stuff in Share to work in your pure Surf app. Also realize that Surf is brand new and still maturing. You’ll be quickly disappointed if you hold it to the same standard as a more widely-used, well-established framework like Seam or Django. Surf is a good option for quick, Alfresco-centric solutions, especially if you think you might want to leverage Alfresco’s browser-based site assembly tool, Web Studio, at some point in the future. (See Do-it-yourself Alfresco Surf Code Camp).

Option 3: Customize the Alfresco “Explorer” web client. There are varying degrees to which you can customize the web client. On one end of the spectrum you’ve got Freemarker “presentation templates” followed closely by XML configuration. On the other end of the spectrum you’ve got more elaborate enhancements you can make using JavaServer Faces (JSF). Customizing the Alfresco Explorer web client should only be considered if you can keep your enhancements to an absolute minimum because:

Alfresco is moving away from JSF in favor of Surf-based clients. The Explorer client will continue to be around, but I wouldn’t expect major efforts to be focused on that client going forward.
JSF-based customizations of the web client can be time-consuming and potentially complex, particularly if you are new to JSF.
For most solutions, you’ll get more customer satisfaction bang out of your coding buck by building a purpose-built, eye-catching, UI designed with your specific use cases in mind than you will by starting with the general-purpose web client and extending from there.

Option 4: Use a portal, community, or WCM platform. This includes PHP-based projects like Drupal (Drupal CMIS Screencast) or Joomla as well as Java-based projects like Liferay and JBoss Portal. This is a good option if you have requirements that match up well with the built-in (or easily added-on) capabilities of those platforms.

It’s worth talking about Java portal servers specifically. I think people are struggling a bit to find The Best Way to integrate Alfresco with a portal. Of course there probably is no single approach that will fit every situation but I think Alfresco (with help from the community) could do more to provide best practices.

Here are the options you have when integrating with a portal:

Portal Option 1: Configure Alfresco to be the replacement JSR-170 repository for the portal. This option seems like more trouble than it is worth. If all you need is what you can get out of JSR-170, you might as well use the already-integrated Jackrabbit repository that most open source portals ship with these days unless you have good reasons not to. I’m open to having my mind changed on this one, but it seems like if you want to use Alfresco and a portal, you’ve got bigger plans that are probably going to require custom portlets anyway.

Portal Option 2: Run Alfresco and the portal in the same JVM (post). This is NOT recommended if you need to scale beyond a small departmental solution and, really, I think with the de-coupling of the web script engine we should consider this one deprecated at this point.

Portal Option 3: Run the Alfresco web script engine and the portal in the same JVM. Like the previous option, this gives you the ability to write web scripts that are wrapped in a portlet but it cuts down on the size of the web app significantly and it frees up your portal to scale independently of the Alfresco repository tier. It’s a fast development cycle once you get it set up. But I haven’t seen great instructions for setting it up yet. Alfresco should document this on their wiki if they are going to support this pattern.

Portal Option 4: Write your own portlets that make services calls. This is the “cleanest” approach because it treats Alfresco like any other back-end you might want to integrate with from the portal. You write custom portlets and have them talk to Alfresco via REST or SOAP. You’ll have to decide how you want to handle authentication with Alfresco.

What about CMIS?

CMIS fits under the “Option 1: Use your favorite programming language” and “Portal Option 4: Write your own portlets” categories. You can make CMIS calls to Alfresco using both REST and SOAP from your own custom code, portlet or otherwise. The nice thing about CMIS is that you can use it to abstract the underlying repository so that (in theory) your front-end code will work with different CMIS-compliant back-ends. Just realize that CMIS isn’t a fully-ratified standard yet and although a CMIS implementation is in the Enterprise version of Alfresco, it isn’t clear to me whether or not you’d be supported if you had a problem. (The last response I saw on this specific question was a Peter Monks tweet saying, “I don’t think so”).

The CMIS standard should be approved by the end-of-the-year and if Alfresco’s past performance is an indicator of the future, they’ll be the first to market with a production-ready, fully-supported CMIS implementation based on the final spec.

Pick your poison

Those are the options as I see them. Each one has trade-offs. Some may become more or less attractive over time as languages, frameworks, and the state of the art evolve. Ultimately, you’re going to have to evaluate which one fits your situation the best. You may have a hard time making a decision, but you have to admit that having to choose from several options is a nice problem to have.

March 3, 2009

Reminder: DFW Alfresco Meet-up is Monday

Don’t forget to sign-up for the first ever DFW Alfresco Meet-up. It’s happening Monday, 3/9 at Ackerman McQueen over in Las Colinas. Plan to arrive around 5:30 and we’ll start our first topic at 6:00. We’ll hear about Ackerman McQueen’s recent Alfresco WCM-based project as well as the portal implementation built on Alfresco DM and Django (a Python-based framework) from the folks over at Neiman Marcus.

We’re letting Optaros pick up the tab on food and drinks so if you’re doing an Alfresco project right now or considering it, you need to join us. Come share what you’ve learned with others and maybe leave with a few new ideas as well.

Address and directions are on the sign-up page.

October 15, 2008

ECM and Open Source presentation and links

Thanks to everyone who attended the AIIM luncheon today at the University of Dallas. It was great to meet you and I appreciated the questions and interest. I’ve posted my slides on SlideShare. As I mentioned, all of the open source resources and other web sites mentioned during the talk are bookmarked on Delicious and tagged under “opensource_ecm_talk”.

September 18, 2008

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.