Lars Trieloff's Collaboration Weblog

I went to one of our customers today to demo our Digital Asset Management System (it seems to be DAM-week, see also my presentation at the Henry Stewart Show) and one of the projects managers told me that he started playing around with Sling and how impressed he was with the power that is hidden in Sling and JCR and how easy it was to build something interesting. So, if you would like to see something cool, just as he did, download CRX Quickstart Edition, which contains CRX (a commerial grade content repository) and Sling (a web application framework built around the concepts of JCR, REST, AJAX, OSGi and Scripting) and take a look at Michael Marth's screencast first steps with CRX Quickstart. (This was the see something cool part)

Having seen something cool, it is time to learn something new, namely building applications using Sling and JCR and CRX Quickstart is a great way of doing to. Aside to the aforementioned screencast, there is a second one: the serverside.com in 15 minutes and the rest of the CRX Quickstart documentation we have assembled.

If you now want to win something shiny, namely a brand new MacBook Pro, apply your newly won knowledge and take part in the Day JCR Cup '08, which is one of the reasons we released CRX Quickstart. We want more developers to learn something new, more developers to build something cool and thought that winning something shiny might be a good incentive to do so.

If you are just reading this weblog, you might have been missing my post on Content Modeling for Java Content Repository (JCR) at dev.day.com.

In this entry I propose an alternative to content modeling with CND and ad-hoc notations based on combining aspects of UML and Fundamental Modeling Concepts.

I would like to welcome my colleague Michael among the bloggers that contribute to PlanetDay. Michael is, among other things, blogging about Scala and JCR, some topics that I have show interest in, so this is a must-have in my reading list.

I am very happy to announce that dev.day.com, the company blog of my employer Day Software that lives up to the great work of my colleague Michael Marth is now adjoined by PlanetDay, an aggregation of private weblogs of Day employees. So if you would like to know what is going on in the minds of Day's employees, take a look at PlanetDay.

I had a short e-mail exchange with Peter Svenson yesterday, who has some really interesting ideas on web development, Javascript and frameworks and wanted to introduce Sling to him. Unfortunately the Sling website is a bit terse on "big picture" introductions, so I though I share my introduction with my blog readers.

What is Sling? This is a fairly complex issue, because Sling combines many aspects. The main idea is that Sling is a web framework that uses a JCR container such as Apache Jackrabbit as repository. The interesting part here is JCR, which is a storage API that allows you to store nodes which can have child nodes and properties, so the best way is to imagine a JCR repository as a giant storage tree or as a file system on stereoids, as it supports typing, transactions, versioning, full-text-search, oberservation and so on. The main role of Sling is being a translator between the storage repository and the client application and this means representing the Nodes in the JCR tree (that have a path) as Resources (as in REST) that have a URI. ;:A resource can have different representations, for instance a blog can have the HTML representation (blog.html) and the Atom feed representation (blog.atom). Representations are not limited to the resource type, there could be another HTML representation, for example the archive page (blog.archive.html). Representations of a resource are generated on GET requests and there are two high-level ways to do it: Servlets (the classical, heavy-weight Java way) or Scripts and Templates. Among the script engines currently supported are Rhino (Javascript), Ruby, Velocity and Freemarker. Basically, there is a script file or servlet for each representation (in our example html.js, html.archive.js and atom.js could be imaginable). If you want to create a new resource type, e.g. blog entry, you just have to create a new folder and put the appropriately named scripts into this folder. Secondly, a resource can have different behaviors. Again, behaviours are implemented either via Servlets or Scripts. The default behavior is to create a node when posting content to a collection, replacing a node when sending a PUT to a resource and deleting a node when sending a DELETE request. You are, however able to override this default behavior by placing scripts into the right folder. These scripts could for instance validate comment contents before creating the node. This is basically where server side scripting comes into play.

Microjax is based on a clever default handling of certain requests. This means representing resources as JSON objects on GET request and processing JSON request entities for PUT and POST. Additionally, Sling and Microjax introduce two Javascript-based templating mechanisms. Sling comes with the built-in ESP, server-side templating mechanism that will allow you to mash up HTML with embedded Javascript that will be executed server-side, e.g.

<ul>
<% foreach (child in node.children) {
 %><a href="${child.path}"><%= child.properties.name %></a><%
} %>
</ul>

Microsling extends this pattern by introducing EST, which allows you to write the same script, which will then be transformed by the server into a proper Javascript with lots of document.write(...) expressions that can be executed on the client-side.

To sum it up: Take a look at Sling, it is an interesting way to build content-centric applications.

In my daily RSS skimming session, two articles managed to stick: Andrew Gent's Web 2.0 and the Lack of Process and Michael Marth's Data First ist gaining traction in the industry. While Andrew criticizes that Web 2.0 technology comes without a process and without structure, opposed to traditional tools in the enterprise such as Content Management Systems (CMS):

By that I mean that the technology itself makes no assumption about how or why the technology would be used. What is the usage model for Twitter? Who should blog? What should you use a wiki for? The answer -- if you bother to ask -- is usually "whatever you want!"

Interestingly Andrew opposes these "process-less technologies", also including blogs not only to CMS, but also to E-Mail, Instant Messaging, IRC and web pages:

Email, for instance. Process is designed into the very core of most of these older technologies. You have an email client. You choose who to send email to. They can read it, reply to it, forward it, save it, and delete it. That's all. The technology embodies the processes previously defined for physical mail.

If this is an example for the process that the tool makes assumptions about, then there is definitely a process for Wikis:

• You read a wiki page
• You edit a wiki page
• Other people read your contribution
• Other people edit the wiki page
• Repeat

There is a process for blogs:

• You write a blog post
• Other people read your blog post
• Other people comment your blog post

Out of this process emerged new technologies that were intended to improve the process. In the blogging space examples are Trackback and CoComment, which improve the process of commenting in a blog. Even twitter has a process, or an etiquette: "Follow your followers, to allow discussions" is one aspect of this etiquette.

And even tools like E-Mail, Instant Messaging and IRC needed some time to develop their own etiquette: How much time am I allowed to let pass before I answer an E-Mail? Should I send instant messages to people with an "away" presence state? It is not the tools that create the process, its the people. People decide how to use Twitter, how to use Blogs, how to use Wikis, how to use E-Mail, how to use Social Networks, how to use Instant Messaging.

People first, process later

If you try to implement technologies the other way round, without either implementing or improving existing processes (which classical enterprise software does), or allowing people to define and develop their own processes (which Enterprise 2.0 does, but the same applies to E-Mail, Instant Messaging, etc), you will fail, because your software is not able to meet the needs of your users.

A similar approach, in a different domain, is described by the keywords data first, structure later. In software development, we are obsessed with structure. Having ontologies, taxonomies, schemas, class hierarchies, typologies, classifications, structured data seems the way to build successful applications. But as in the enterprise, too much structure without relation to the reality (here people, there data) will render your classification useless. Therefore a new class of frameworks is emerging that does not enforce structured data, but allows structurable data. If you want to know what this means in terms of technology, have another look at Data first is gaining traction in the industry.

Congratulations to Michael Marth for the successful softlaunch of dev.day.com, the developer portal for all things related to Jackrabbit, JCR, CRX, Sling and Microsling. The first part in the picture is a blog with the witty title "content goes here", which is Day's first step into blogging and will definitely not the last one.

If you are interested in Jackrabbit, JCR, Sling, content management and all the other exciting stuff we do at Day, point your feed reader to http://feeds.feedburner.com/contentGoesHereBlog.

Dave Johnson's wrap-up of the ApacheCon contains some interesting pieces: Of course he mentions the Shindig proposal, which I hold as one of the most interesting developments in the social networking space and he has written a longer paragraph on combining Roller (the weblog software) and Jackrabbit (the JCR repository that is the core of Day's CRX).

The idea of using a content management system to store Roller content keeps on coming up. At ApacheCon EU earlier this year, I spent some time talking to Lars Trieloff (who now works for CMS vendor Day Software) about implementing the Roller back-end interfaces using the Java Content Repository (JCR) APIs instead of the Java Persistence API (JPA) that we use now.

My rationale then was, to allow true free form collaboration in Mindquarry, we needed a weblog system. Mindquarry is based on Jackrabbit and I did not want to open another repository backend then, so I thought about creating a JCR-based backend for Roller that would easily integrate with Mindquarry.

At this ApacheCon, Noel Bergman brought up the topic a couple of times and pointed out that Day Software, has blog and wiki modules that are both backed by JCR. We could do the same thing: create version of Apache Roller and Apache JSPWiki (incubating) that share the same content repository.

The main advantage is that Roller and JSPWiki are content-centric applications. Every well-designed content-centric application moves sooner or later into the direction of having a separate repository layer. In JSPWiki the repository-layer allows you to have different backends, from flat files, to RCS to Apache Roller. In Roller there is a domain-specific repository implementation that is called "model", but if you have read my recent posts on microsling, you will note that using Model-View-Controller (MVC) for content-centric applications is disgusing the content-centric nature of the application, which would need a Content-Behavior-Appearance (CBA) model.

Later, Jukka Zitting (who also works for Day Software), suggested the idea of implementing JPA itself with JCR, thus allowing Roller to store its content in a CMS in a totally transparent fashion. This topic is interesting to me, but I don't fully understand the benefits of backing blogs and wikis with JCR. What new use cases would this support? How do the interesting features of JCR, like versioning for example, bubble up through Roller -- especially if Roller is to support both RDBMS and CMS back-ends?

I had a chat with Jukka yesterday in which he pointed out that implementing JPA based on JCR could be a very-cost effective solution and it might be the ideal way to go to migrate applications stuck with relational or object-relational backends to a content-based backend. Of couse, you would lose many of the advanced features that JCR offers you like full-text-search, observations, versioning because you have to mainatain backwards-compatibility to relational databases.

As always, this is a questions of frameworks and the right time to start a project. When the Roller project was started, there was no JCR, no Sling and no practical and standardized way of implementing content-centric-applications. With this in mind, it is easy to map some of the features JCR is offering to the needs of a blog application:

versioning

keeping all versions of a blog post, allowing incremental writing and backup

observations

notifications for new comments

workspaces

having a draft and a publish area for posts

hierarchy

posts belong to weblogs, comments to posts, etc.

export

backup

queries

tagging, categories, full-text-search

Disclaimer: I am Day's product manager for collaboration products, namely Blog and Wiki and I am a long-time user of Roller and JSPWiki. This blog post was written on Roller, using the JSPWiki plugin.

In the first sections of this series we learned the basics of content-centric architectures and how a content-centric framework looks like. In this iteration I am going to take a closer look at microsling and show how it maps structured data of different types.

The data microsling deals with has following natures:

• HTTP Requests
• HTTP Response
• JCR Nodes
• Scripts (Behaviors or Renderers)

The first part of this mapping discussion will only cover mapping of HTTP requests to JCR Nodes.

Mapping HTTP Requests to JCR Nodes

A simplistic description of a HTTP Request can be described as "A request URI, a request method and a number of named request parameters". A JCR node can be described (again grossly simplified) as "A resource path and a number of named properties and a number of named child nodes". Following data will be mapped:

• request URI to resource path (called content resolution)
• request parameter to property

Content Resolution

The guiding principle for content resolution in microsling is that for every request path, there is at least one resource path that is a substring of this request path. microsling tries to find the longest resource path that is a substring of the request path, using / and . as path delimiters. For instance, for the request path /weblogs/lars/entry/an_architecture_for_content_centric2.html/view following resource paths are possible:

• /weblogs/lars/entry/an_architecture_for_content_centric2.html/view
• /weblogs/lars/entry/an_architecture_for_content_centric2.html
• /weblogs/lars/entry/an_architecture_for_content_centric2
• /weblogs/lars/entry
• /weblogs/lars
• /weblogs
• /

because of the final fallback to / you can be sure, there is always content that can be mapped to a request path.

However, whatever content path has been found, some additional information will be made available for request processing. This information is:

• The extension: In this case the extension would be html. This comes handy, when delivering more than one representation for one resource, for instance in a web calendar the extensions html, json, atom, ics come to mind.
• The selector: The selector is everything that comes before the extension, but is prepended by a dot. This allows selecting more than one view for one extension, for instance /weblog.html would give the standard view of the weblog entries, but /weblog.gallery.html would create a photo-gallery for a photo weblog. There can be more than one selector at the same time, e.g. /weblog.archive.1.html
• The suffix: basically everything that comes after the extension, in the above example /view. With the suffix you could for instance address parts of a resource.
• The unused content path. If for instance the request path in the above example has been resolved to /weblogs/lars/entry, /an_architecture_for_content_centric2 would be the unused content path. With this information you could create an error page or a form that allows you to create the non-existing weblog entry.

Property Resolution

microsling maps request parameters in some cases to properties of a content node. This is a useful way of creating new content nodes or updating existing nodes with a simple form. The default mapping will map every single-value request parameter to the same name node property. Multi-value request-parameters are mapped to multi-value node properties. New nodes created during this mapping will have the type nt:unstructured, basically allowing every content type.

In the next series I will cover mapping of content to scripts, called script resolution.

• despite the name, Java is not made for Java Content Repository API, you need something more dynamic
• Is there something like JSDoc for Rhino, that allows me to generate documentation for my Scriptable implementations automatically?
• Farm Fetish

There are four times as many Americans living in urban than rural areas. There are four times as many people sucking back coffee in New York city alone than make a living farming. According to the Burea of Labor, there are just as many people employed in Architecture and Engineering as farming, hell, 3 million people working in Computer and Mathematical jobs. But when one of these "What does America think about culture" pieces comes on, do I ever see a mid-30's software engineer onscreen bitching about having to download BitTorrents of "The IT Crowd"?

• In the web office market, Google docs and Google spreadsheets hold a market share of 92%. The report calls these "online collaborative productivity tools". Interesting segmentation.

One thing I enjoyed most at the HPI and Mindquarry were discussions with Hagen about architectures for content-centric applications. Interestingly after having some discussions, reading blog entries and mailing list posts with David (where is your blog), Carsten and Bertrand, I am surprised to see Sling and Microsling which looks like many of Hagen's ideas having come to life.

Unfortunately the Sling website does not have a good description of the big picture and overall architectural ideas, so I will try to explain the ideas I have identified in the next blog posts. The goal is to go from the very high level of abstraction down to concrete code and examples.

Let's start with the helicopter perspective: Users want to interact with content, want to read, write and modify content.

(I am using the fundamental modeling concepts notation here. Boxes with angled corner are active system components, boxes with rounded corners are passive system components, storage.)

The way we usually implement this interaction is trough a web application that works as a proxy for the content.

(The small bubble between user and web application is a communication channel, indicating that the user interacts with the web application by means of HTTP and the web browser)

Dealing with content usually means providing one human-readable representation of the content through a component I call renderer and providing a behavior for dealing with user inputs. This means validating user input, writing input to the storage if it is correct or triggering custom actions.

In the next issue of this mini-series I will further examine the nature of renderers and behaviors and show how a framework can implement this architecture.

We recently released Mindquarry 1.1beta. Most of the changes center around the user interface.

• we have re-worked the user interface using an UCD-process. In my point of view this gives us a much better usability and has made me from an user-centric-design agnostic to a true believer in UCD.
• Activity timeline (based on the SIMILE Timeline) to view older versions of files, Wiki pages, tasks. When I saw Stefano's presentation at ApacheCon Europe I learned that the SIMILE folks created this widget to lure ingenuous developers into creating a web of data. The widget is really easy to use, I only had to write a small wrapper script to turn it into a Dojo Widget for SIMILE Timeline.
• Include tables and images in Wiki pages. This is a side-effect of the transition to Dojo 0.4.1 that Jeremy contributed to Cocoon in January and that took us some time to pick up, because the API and implementation of the servlet services we are using heavily had changed (before they were called block servlets)
• Conveniently link to a file, a task or another Wiki page from within the Wiki. In the window for adding a link, you can search for the item you intend to reference. This is another heavy Dojo widget that uses the JSON data we produce internally.
• Desktop client for Mac. The Desktop Client for Mac 1.1-beta included a bug, this is why I released 1.1-rc as a release candidate today.

Especially the activity timeline is a huge step forward for us, because it brings us closer to our goal of an ultimate undo/redo of all collaborative content within Mindquarry. This allows teams to have full revision control and provides a good overview of a team's productivity. We are already versioning all contents since 1.0 thanks to the ease of versioning JCR and Jackrabbit provide and have found a convenient interface to access this data using the timeline widget.

The Mac client has proven to be very useful while testing it internally at Mindquarry. Most of us run Mac OS X and of course we use Mindquarry for daily work to share files. My colleagues especially like that they can now easily comprehend which files have been added by others to the server's files repository and also see the changes to the local copy they made to the repository on their computer. Simply by hitting the "Synchronize" button, they can commit and retrieve changed or added files. Furthermore, they also value that they can use the Mac client to manage tasks offline and synchronize once back online again.

You'll find more information about this release on the Mindquarry 1.1 Release page. This release would have been impossible without the great work of open source communities of our core components, especially the Apache Cocoon, Apache Jackrabbit and Dojo Toolkit community.

When you are building applications using Spring and JCR with a repository like Apache Jackrabbit, the newly released JCR Spring module (see org.springmodules: spring-modules-jcr 0.7) might be for you.

It contains Spring FactoryBeans that allow you to access JCR repositories directly, via RMI or JNDI.

Happy new year to all my readers. This morning, a pice by Carlos E. Perez caught my eye:Software Development Trends for 2007. Some of the trends are already catched up by Mindquarry, e.g.

• Dynamic Programming Languages - Mindquarry's core functionality is written in dynamic languages like Javascript and declarative programming languages like XSLT and JX
• Java Content Repository - Mindquarry uses Apache Jackrabbit, because "Organizations will begin to worry about their creaky poorly supported CMS and begin towards safeguarding their content assets by migrating to a JCR implementation."
• Life after EJB - Mindquarry uses Cocoon 2.2 which in turn uses Spring as a component framework and we are very happy with it.