Lars Trieloff's Collaboration Weblog

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've uploaded my second presentation "Mindquarry for Cocoon Users" to slideshare.net. And as far as I see, Ugo has added his presentation to the Cocoon group at slideshare.net as well.

John Udell reviews RESTful Web Services, an O'Reilly book by Leonard Richardson and Sam Ruby. I buy the book. That's what a review should look like. I do not need to read reviews of books I am not going to read.