Lars Trieloff's Collaboration Weblog

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.

In the first part of my micro-series I have come to the conclusion that a content-centric web application allows the user to interact with the content by the means of renderers and behaviors. These renderers and behaviors can be expressed by means of pipelines and processes.

A pipeline takes the existing content, transforms it several times and finally sends a new representation of the content to the client. This concept is anything but new, one of the most successful web application frameworks at apache is actually Apache Cocoon where pipelines are based on the idea of transforming XML events by means of XSLT, STX and other transformation languages.

Content behaviors can be seen as processes in the sense of business processes that trigger events, process input data and eventually manipulate content. A process can be expressed formally by a program or a script, or a graphical process programming language like BPMN.

If you take a look at a typical processing pipeline used by Cocoon, you will see something like this:

<map:match pattern="myThirdPipeline">
  <map:generate src="myXMLFile.xml" type="file" />
  <map:select type="resource-exists">
    <map:when test="myIncludeFile.xml">
     <map:transform src="myXML2include.xslt" type="xslt" />
     <map:transform type="include" />
    </map:when>
  </map:select>
  <map:transform src="myXml2PdfFile.xslt" type="xslt"/>
  <map:serialize type="fo2pdf"/>
</map:match>

The constructs involved here splits (<map:select>) conditions (<map:when>) and joins (</map:select>), activities ({<map:transform>}) can be found with different names in any workflow language, thus another way to interpret rendering pipelines is to see them as processes as well.

A content centric web framework's most important task is mapping content to processes and providing an execution environment for these processes.

(The FMC-construct used here is called structure variance. It means that the framework dynamically creates the renderer and behavior actors, depending on the content requested.) The framework maps a HTTP request to a content resource, identifies the process description for the kind of request ('real' processes that change resources for PUT, processes with side-effects for 'POST' and rendering processes for GET requests), e.g. a script or template file, dynamically instantiates the actor by interpreting the script or running the template engine and connects the request-handling actor to the content and the request and response.

In the next section of the series I will show how a framework like Sling handles request-to-content-mapping, content-to-process-mapping and how processes are enacted.

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.

I started playing around with Bertrand's microsling (P.S. do not google for the name of the project), which is a minimalized version of the Apache Sling (incubating) framework. Microsling supports two templating languages, Velocity and ESP which is a JSTE-inspired JSP-like syntax for Javascript. As I am a fan of server-side Javascript, I opted for the ESP template language and noted there is no syntax highlighting support in my editor.

With jEdit this is no problem, however. I just copied and adjusted the JSP syntax highlighting definition file, adopted it to ESP and got fine syntax highlighting for ESP files.

All you need to do is download esp.xml, put it into your jEdit-modes directory (either in the jEdit application folder or in $HOME/.jedit/), and add following line to the catalog file in the same directory:

<MODE NAME="esp" FILE="esp.xml" FILE_NAME_GLOB="*.esp" />

Update: As I learned from Felix, ESP is not inspired by JSTE, it is just very similar. In fact ESP is being used since 2001 by Day. And as I learned from Betrand, it is not Bertrand's microsling, he was just the first to write about it.