Content centric applications with Alfresco

I’m finally doing real work on top of Alfresco – and starting to really like the platform. Why you might ask, and I will answer – in a while. But before that a little recap on what the CMS-landscape looks like from my point of view. I’ve been using, researching and tinkering with numerous different content management systems throughout the years – but haven’t been quite thoroughly satisfied with any of the systems I’ve had to work with, though I have had a lot of fun and profits made with each one of them.

First CMS systems I tinkered with were bespoke systems made with PHP in the early days of my career. There wasn’t any popular projects yet available as people were only just building their first own systems and then realizing how cumbersome and hard work it is to build your own CMS system from the ground up, maintain it and develop all the necessary features needed eventually. Getting things off the ground is easy, but then you start to get the need for more complex features.

Zope / Plone was my first love in the real CMS landscape. Zope’s Contet Management Framework had brilliant ideas and the whole object database was an idea before it’s time. Instead of thinking rows in the database you had content objects in the object database, forming object trees and structures just like the created website or application would do. You did not think in relational terms, but worked only with objects. Common services were also objects inside the site and you could add functionality into the website by creating own services or by writing python scripts into the site. User interface for the site was constructed as a skin, which could be changed on runtime depending on the needs and capabilities of the user’s browser.

Initial user interface of the CMF was rubbish – truly rubbish, but that did not matter as CMF was about building a platform to build content management applications.It took Plone to make CMF usable and pretty. And Plone made CMF really take off and get people excited, as Plone made CMF look and feel usable straight out of the box. It was the Apple experience. The most important thing Plone brought to the table however were the creation of new communities of exciting people building applications and solutions on top of it – using Plone to solve real life problems small organizations had. Plone had and has an exciting and large community of hackers working for and with it.

My breakup with Zope and plone came during a time when Zope’s and Plone’s future were quite gloom. There were big changes coming in the near future, breaking clearly from the past towards Zope 3, bringing in new patterns, new architecture and incompatibility. In a way all the changes that were on the way were for the good, but it was hard to keep your belief and keep believing when already a niche community was in turmoil and there were fears that everything you knew would be unusable in the future and the benefits of the future uncertain.

I made a business decision with a friend of mine, ditching python, Zope and Plone and switching into the vibrant java-ecosystem. And sooner than later other people also jumped the ship, including Nuxeo — french ECM manufacturer, who ported their system from Python to Java infrastructure almost in no time. And then their business started to boom.

WIth the skills and ideas of content management learned from CMF and Plone, working with java language and infrastructure was a breeze. However the thing missing was a really good content management framework or tool which would fit the idea and ideas I had about content management. I tried different systems and saw some interesting ideas and things, for example in OpenCMS – which is really good and mature web content management system, something that you could really take a look at if you are in the business of just managing a website or communication focused extranet. Maturity brings stability and also some types of constraints for your development, but if you can live with those – then OpenCMS could be your thing.

But then there is Alfresco.

Alfresco’s ideas are built on top of history of working and developing ECM-systems – and you can see it. At first it feels like a large and complex system with ugly and hard to use standard user interface, because that is exactly what it is. However with time or with some education you start to see the beauty in it: how well it is modularized, how powerful set of services it has out of the box, how easy it to extend and how well crafted it is under the hood. As you learn and start to understand how Alfresco works, you also appreciate the clarity of the code. I have been reading bits and pieces of code from here and there, and haven’t yet had any WTF-moment, which is a remarkable proof of the rigorous quality and QA practices Alfresco engineers have.

Alfresco is big and it is complex, but it has a lot going for it. In just few years there has been published a few hugely important books about Alfresco, which have opened and explained concepts and ideas used in the Alfresco platform. Instead of wasting ages reading source code, wiki articles and forum postings while trying to learn and understand Alfresco, these few books ( Alfresco Developer Guide and Professional Alfresco ) get you up to speed in no time and teach you the right ideas about the platform. Combine that with all the commercial offerings available for developers, barriers of entry into the world of Alfresco are lower than ever.

Alfresco does also have a community, though it is a little different than communities of non commercial open source software. The great thing about the community is it’s professionalism. Though there are abundance of unanswered technical posts in the forums, there are also great replies going into the lengths about different aspects of Alfresco written by Alfresco engineers and partners working professionally with the software. People collaborate and communicate, and more importantly also share tips and best practices on how to use the features they have at their disposal. Because of the open issue tracker and open forums available to the community, it is possible to educate yourself and your fellow developers about potential bugs, and work around them. For example this bug proved to be something that bit me, but with the help of google I found a forum posting describing the issue in Jira and a workaround, which was linked to the jira issue. Instead of having to cough up for expensive support, people who have time to spend can work on their own and fix problems with other developers.

All above is sweet and interesting, but only side dish – the actual beef is much more interesting: Alfresco allows me to model content management solutions like I want to.

Everything in Alfresco is a node. Sooner you understand that, better off you are.

Nodes can be of certain types – and type describes what kind of fields / attributes / properties nodes have. Think of it as class definitions.

Besides type definitions, properties can be added to nodes via aspects. Aspects are cross cutting definitions that are shared by multiple types. Those fields defined in the aspects are added to the node, when aspect is added to it. Simple as that.

Nodes reside in repositories, which in turn are trees of nodes.

Groups of services are provided for you to manage and process nodes. Services provide higher level abstraction to on top of nodes, giving you high performance tools to manage language versions, versioning and for example transformations of content from one format to another. Services can work straight on the nodes or hide their inner workings into separate repository, like the versioning service does. Below the surface everything is still a node, so as you start to go through the code – you can see and understand how it works, but most likely you do not need to know.

There are few different APIs you can use to programmatically manage your content. Lowest level APIs are Java foundation apis which can expose all the internals of Alfresco to your use. Programming with foundation APIs can be a lot of work as you need to manually take care of lots of things and in general it is not recommended unless you have to do it. If you have a integrated java application written in Spring framework, then it might actually be the best option for you. CMIS offers young standards based web service API to work with, which is interesting for you if you work in collaborative environment with multiple different content management systems. However with CMIS you lose some of the features of Alfresco repository, so I wouldn’t use it unless I need and want the API compatibility. Naturally there are traditional SOAP based APIs available for those who want to use them. I haven’t personally used them so I can’t say anything good or bad about them. For me the best API so far has been the webscripts framework which allows me to build custom REST-APIs for my application needs and communicate among others in XML, HTML and JSON. Webscripts framework has it’s own MVC framework, where you have definition files for the script, javascript controller for the logic and templates written in Freemarker.

Initially I was really skeptical about webscripts and started to work in a project with foundation APIs. Sooner than later I found out how much work working with foundation APIs were – and how slow the development was with traditional compile, deploy, test-cycle. I studied more and finally read from Professional Alfresco fantastic introduction to webscripts-framework and was in love. All the important services are exposed to the framework and even though you do lose the IDE support for objects, in reality objects and services used are so simple that working in javascript is a breeze.

The most important thing in webscripts framework however is the development speed. You can develop scripts on top of the running Alfresco system via the web client, testing out scripts as you write them — without the need to redeploy the application after every change. Once your scripts are ready, you can move them into your project and have them alongside your java code.

With webscripts you are free to create your actual applications in any platform you like – and communicate with your content repository over HTTP in standard like JSON or XML. In our project the applications are written in Spring framework and deployed into Liferay portal. Portlet applications then use Spring Frameworks excellent RestTemplate to make queries into the repository and get / store content. And once you lern to use javascript in Alfresco, you realize that it can be used also elsewhere on the platform. For example if you use workflows, you can code actions and code to be run within the workflow as javascript.

Instead of writing your own content management user interfaces, you can extend or configure the standard webclient – which is Java Server Faces based application. With few configurations you can expose your custom content types and custom actions into the default Alfresco web client. Actions are pieces of code, which capsulate common operations into a command that can be run from content management scripts or from the user interface. This way you can create new services and functionality on to the platform and just expose that functionality into existing UI.

As Alfresco provides just a simple, but powerful user interface and great framework for content management, there are more than one way to do things in Alfresco. And in content management that is a good thing as requirements and specifications change. There are no right or wrong answers as they depend so much on the context. If you want great things right from the box, this can be frustrating – but if you need to build complex custom solutions, this can also be a bliss.

Alfresco takes some time to know, but it can open a whole new world of possibilities for content centric applications. Even though Alfresco can feel like using a cannon to shoot a fly if your use cases are relatively simple, but eventually you will see that Alfresco’s versatility and powerful features can come into good use and save loads of work from you in the long run.

When comparing Alfresco to your own solutions it is also important to remember that Alfresco is also a real commercial application with support options and custom application development available from different companies. That open different strategic opportunities for your application’s future and maintenance. On the other hand Alfresco is also a real open source platform, with it’s own community and free extensions available from Alfresco Forge.

With the time spent so far on Alfresco, I have come to the conclusion that Alfresco is definitely an interesting platform and worthwhile player to be watched in ECM landscape. It is also an excellent platform to be used in your own content centric applications, even though you would not need all the ’enterprisey’ features and possibilities in your work.

I’m already signed up for this years Alfresco Developer Conference in Paris, and looking forward seeing other developers and architects there.

Kategoria(t): java, liferay, programming, spring, technology. Lisää kestolinkki kirjanmerkkeihisi.


Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

Olet kommentoimassa -tilin nimissä. Log Out /  Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )


Muodostetaan yhteyttä palveluun %s