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.

With an social activity index hitting a new all-time low, after weeks of failing to find time for blogging, I would like to give a short status update. I have been invited by Peter Svensson to speak about Apache Sling at the second Web Monday in Stockholm. As Peter is the sole organizer of Web Monday in Stockholm, he took the freedom of letting it happen tuesdays, but still it should not be confused with Web Tuesday (of Zurich). In preparation of Web Monday Stockholm I am spending every free minute with coding a Dojo+µsling integration that I want to showcase in two days, and that will eventually be a part of Peter's Bunkai project.

After a long time without posting any Sling-related content, here is a short entry:

I am going to present µjax, the micro AJAX framework that comes with Sling at the Web Montag in Berlin. Today. This means I am right now in the midst of preparing the demo, preparing slides and getting ready for getting to Berlin. I will post the slide here and on slideshare afterwards.

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.

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.