Here's an inspiration if you are building corporate web sites: www.mercedes-benz.de has just been redesigned and launched again. The site is very rich with loads of dynamic HTML and Flash, but nevertheless manages to keep a clean and professional look. IMO it's a great example for a corporate web site.

The CMS underlying mercedes-benz.de is Communique.

(The site is in German, but even if you cannot understand German, clicking around a bit will give you an impression. There is also a press release in English.)

Before we can get our feet wet with microsling I would like to spend another blog post on theory and explain two important concepts in microsling: the mapping of requests to resources and the script selection.

Microsling is content-centric. This means that each (http) request is mapped onto a JCR resource, i.e. a repository node. This is very different from other web frameworks you might be familiar with, say, Struts or Rails. In these conventional frameworks a request is mapped onto a controller, i.e. a url really addresses application code, so the application developer needs to implement some application logic that retrieves model data and passes it on to the view.

Just like Rails or Struts, microsling implements a model-view-controller architecture. However, in microsling a request addresses a piece of content. The mapping between request and model (data, content) is accomplished through the url so there is no need for further custom mapping logic.

Node selection

So, how does this work in detail? Consider an http request for the url:

First, microsling will look in the repository for a file located at exactly this location. If such a file is found, it will be streamed into the response as is. This behavior allows you to use microsling as a little web server and store your web application's binary data in the repository as well.

However, if there is no file to be found microsling will look for a repository node located at:

(i.e. it drops the file extension). If this node cannot be found it will truncate the node path and look for:

If this node does not exist either, it will look for

and so on. If nothing can be found under these paths it will finally select the special resource called "NonExistingResource". Consequently, there will always be a resource that each request can be mapped onto.

Script selection

Now that microsling has found a node it moves on to the second step and selects a script to display this node. All of the scripts are stored in the repository as well. They reside in subfolders of "/sling/scripts", which are regular JCR nodes. Usually these nodes would be of type nt:folder (for example when they are created through WebDAV), but they do not have to be.

The selection algorithm for finding the right script to render the node takes into account the exact request url and the resource type of the selected resource. Let's go through the algorithm step-by-step:

1. Choosing the script folder: In a first step the repository folder that contains the script is determined.
1. The selected resource will have a resource type. This resource type can be set explicitly by adding a special property named "sling:resourceType" to the node. In this case the value of this property is the resource type of the node. Say the value is "jobs/jobOffer", then microsling will select a script from the repository folder at "/sling/scripts/jobs/jobOffer/".
   
   If the property "sling:resourceType" does not exist, the resource type will be determined from the node type of the node. Let's assume the node type is "nt:unstructured". In that case the folder located at "/sling/scripts/nt/unstructured/" will be selected (all colons in the resource type will be replaced by slashes).
2. Next, there can be a so-called "selector" in the request url. It is an optional part that is appended to the resource and separated by a dot. Confused? Here's an example: if the requested url is /content/corporate/jobs/developer.summary.html the part "summary" would be the selector. If such a selector is present in the request it is appended to the path from above.
   
   In this case the resulting path would be either "/sling/scripts/summary/jobs/jobOffer/" or "/sling/scripts/summary/nt/unstructured/" respectively.
   
   Selectors are useful for creating different views on the same content item, e.g. to have a summary view and a full length view for an article.
2. Once the folder is determined, the actual script file will be selected from this folder according to this algorithm:
1. The file name will be the extension of the request, i.e. in our example from above /content/corporate/jobs/developer.summary.html the selected file will be named "html". In this way there can be various scripts for various response formats, one that handles requests for html pages, another one that handles json responses (in an Ajax application) and another that handles requests for PDFs.
2. In order to get the complete file name of the script file we still need its file extension. It is through this file extension that microsling determines the script engine that shall process the script. For example, if the script file has an extension ".esp" then the (server-side) Javascript engine will execute the script, if it is ".rb" then JRuby will execute it. As such, the script author needs to name the script file's extension according to the scripting language he chooses to use. For a script written in JavaScript to produce html the file name would be "html.esp".

To sum up the script resolution so far, when microsling looks for a script it builds the path as:

Where:

• RT is the resource type
• (For the http GET method) ME is the extension found in the request (html, xml, etc.), always in lowercase.
• EXT is an extension that is acceptable for one of microsling's script engines (e.g. .esp, .rb, etc)

http method

You might have just stumbled over the "for the http GET method" bit and wondered "what about POST"? In fact, in addition to an extension like "html", ME can also be a http method like "POST". So if a POST request comes in, microsling will look for a script named POST., e.g. POST.esp. The convention is that http methods are all uppercase, whereas response types like "html" or "pdf" are all lowercase.

This should be enough background information to get you started. Don't worry, it may look a bit overwhelming at first glance, but you will get used to it quite quickly. Please find below an image representing the whole process.

There are some more subtleties and mechanisms in the url mapping to file names, taking into account additional parts of the url. My colleague Lars Trieloff has written an excellent post on his blog that goes into some more detail.

Thanks a lot to Bertrand, Felix, Alison and David for reviewing this post and providing a lot of corrections and useful feedback.

A couple Day employees that are active in the open source community gave talks at this year's ApacheCon (US) in Atlanta. They covered a wide range of topics (from architecture to new Apache projects and Java libraries). Find some of the abstracts and slides below. Also, during the conference the Apache podcast "FeatherCast" interviewed Felix Meschberger about Sling.

Bertrand Delacretaz: XSLT and XPath - Without the Pain!

XPath expressions, the underlying tree model and the node type definitions are essential knowledge for writing efficient XSLT transforms. Yet, many people use XSLT without really understanding these important concepts. In this talk we present these essential elements, and help the audience focus on what is important to learn XPath and XSLT. We also define a minimal "learning subset" of XSLT instructions, which is sufficient for many transforms, and helps in preventing the overuse of procedural constructs. Forget about xsl:if and xsl:choose! Our real-life code examples will show you how to avoid writing procedural XSLT code, in order to efficiently use this powerful XML transformation language.

| View | Upload your own

Carsten Ziegeler: Getting Up to Speed with Apache iBatis

Getting data from a database and storing information into a database is a very common task for a Java developer. Possible solutions range from JDBC to full-blown object-relational mappers like Hibernate or OJB. The Apache iBatis project is another choice which provides more sophisticated support than JDBC but is lightweight compared to ORMs. This session introduces the idea behind iBatis and demonstrates the basic mapping features. The session will provide valuable information when to choose iBatis over other persistence solutions and how to get it running quickly and efficiently.

| View | Upload your own

Carsten Ziegeler and Bertrand Delacretaz: JCR in Action - Content-based Applications with Apache Jackrabbit

The Java Content Repository API (JCR) is the ideal solution to get hierarchical structured content from various content repositories. The provided API allows the development of content based applications which are independent from the repository, being it a database, some legacy storage or the file system. To demonstrate the basic architecture of such applications, an example content management application will be developed during the session. Basic techniques will be explained including navigation, searching and observations by using the Apache Jackrabbit project.

| View | Upload your own

Carsten Ziegeler: Apache Sanselan - A Pure-Java Image Library (Fast Feather Track)

| View | Upload your own

Felix Meschberger: Apache Sling - A Content Based Web Application Framework (Fast Feather Track)

Building on top of Java Content Repositories, implemented as OSGi Bundles, Sling is an extensible Web Application framework enabling quick development of flexible content based applications. Sling has the persistence layer already built in, still the developer is not forced into using low level persistence API by employing the flexible, configurable the Jackrabbit Object Content Mapping. Extensibility of the framework to build and extend applications is provided by employing the OSGi specification to build a modular and highly dynamic system: Extensions can be installed, updated and uninstalled at runtime without forcing the developer and system administrator into time consuming and error prone stop-build-start cycles. This presentation highlights the goals of the project and shows how these goals are met.

| View | Upload your own

Jukka Zitting: Apache Tika - An extensible, configurable content-analysis framework (Fast Feather Track)

Tika is a new content analysis framework borne from the desire to factor our commonality from the Apache Nutch search engine framework. Tika provides a mime detection framework, an extensible parsing framework and metadata environment for content analysis. Though in its nascent stages, progress on Tika has recently taken shape and the project is nearing a stable 0.1 release.

| View | Upload your own

Roy T. Fielding: A little REST and Relaxation

Representational State Transfer (REST) is an architectural style that I developed while improving the core Web protocols (URI, HTTP, and HTML) and leading them through the IETF standardization process. I later described REST as the primary example in my dissertation. Since then, REST has been used (and sometimes abused) by many people throughout the world as a source of guidance for Web application design. But is the REST that we hear about today the same as what I defined in my dissertation, or has it taken on the baggage that comes with an industry buzzword? This talk will provide a real introduction to REST and the design goals behind its evolution as the Web's arhitectural style. This is not about XML-over-HTTP as an alternative to SOAP, nor about "resource-oriented" frameworks that help simplify CRUD operations, but rather about the design goals and trade-offs that influence the development of network-based applications. I will also describe what happens when we relax some of the REST constraints, and how such relaxation is impacting the design of the waka protocol as a replacement for HTTP.

| View | Upload your own

Tim Berners Lee recently coined the term "The Graph". The idea here is that computer networks undergo a conceptual evolution. The starting point, the Net (internet) connects computers, abstracting from the cables between computers allowing the creation of networked applications. The most successful networked application became known as the Web (world wide web) and provided another abstraction. It is not the computers we care about, it is the documents (resources) and links between them (hyperlinks). This web is what most content management systems and content repositories care about - they manage documents after all.

The Graph is nothing else than the realization that we actually do not care about documents (or even the computers where these documents are stored), but about the things that are described by the documents. A document can describe a person, an idea, a place. And in the same way as people are connected to each other, as ideas are connected to people and people to places, documents can be used to describe these connections by the means of hyperlinks or more advanced technologies like RDF.

To refrain this thought - the graph is not about the documents and their connections, but about the things described in the documents and their relations, about the document's contents. The graph is about content and content relations.

If you are a user of content management system or a content repository, if you are developing applications that deal with content, if you are a vendor of a content repository or content management systems there are some relevant implications for you:
Your content repository should be about content, not about data or documents. It should allow you to deal with content in all representations, from highly structured to unstructured. It should allow you to unify access over all content stores. It should allow you to expose your content to the outside, allowing you to build a stronger graph.

If you are looking for this kind of content repository, you should have a look at CRX and its open source companion Apache Jackrabbit.

Next week on Tuesday (27-nov-2007) I am going to speak at the "CIO Summit" at the Fairmont Palace in Montreux, Switzerland.


View Larger Map

The CIO Summit is a great opportunity for me to explain the crucial importance of the content repository and content repository standards when implementing a successful CMS strategy.

My presentation will be in German and based on the audience "unusually business oriented".

If you happen to be at the event feel free to drop by.

Update: English slide deck below

| View | Upload your own

During the last two or three years there has been a growing interest within the software industry in agile methods, rapid application development (RAD) and simplicity. It seems that the pendulum is swinging back from heavy-handed enterprise dogmas. "Getting things done" is of value again.

This development has largely been triggered, and embodied, by full-stack web frameworks like Ruby on Rails, Django, Seam, Rife or Grails. They proved that solid engineering and being able to build a web application in 15 minutes are not mutually exclusive. However, all of these frameworks use a relational data base for persistence. Why? RDBMSs possess characteristics that render them less than ideal for rapid application development. In particular, the data needs to be structured upfront and is hard to change as the application changes. I believe it’s time to move on to JCRs.

Content repositories provide a lot of the core infrastructure that many web applications need straight out of the box. There is fine granular access control, versioning, search, change notification etc. But most importantly, JCRs provide dynamic extensibility of the node types. This is especially helpful in RAD environments where most requirements are unknown and therefore, changes to the data structure must be painless.

This is where microsling comes in. It is a web application framework that can be used for RAD, but it uses a JCR for persistence. The content is presented and modified through server-side scripts (written in JavaScript, Ruby or other scripting languages). These scripts have access to the repository objects, like the requested node and its properties, so that script authors can easily generate output such as a web page.

Just like the content they are supposed to render, the scripts are stored in the repository ("Everything is content", remember?). Since the repository can be mounted as a WebDAV drive there is no more need to re-deploy a war file as is the case for Java-based web applications. A simple "save" and "reload" in the browser is enough to see your changes. This is a BIG deal when you want to write a web application in a hurry.

The microsling approach also dramatically lowers the entry barrier to writing JCR-based web applications in terms of required skills. You do not need to code Java, JSPs etc anymore, JavaScript is enough. At last, using a JCR may become attractive to the PHP crowd.

Microsling is really a sub-project of project "Sling", which is currently in incubator status at Apache. Sling has similar aims to those of microsling but is focused on more enterprise-relevant features. For example, it is built upon OSGi which allows powerful plugin management (you might know OSGi from Eclipse). Think of Sling as some kind of upgrade path for later, but you do not need to be concerned with it at the beginning.

In the next posts I will take a closer look at microsling and prepare a tutorial to get you started playing around with it.

OK, here it is: the first bit of content on Day's brand new and shiny developer portal dev.day.com. This portal is all about Java Content Repositories and the technologies related to them. We cover core repository software like Apache Jackrabbit and CRX, JCR-based web frameworks such as Sling and microsling and JCR-based content management systems like Communiqué.

Sounds good? Glad to hear that. But don't go looking for content just yet. We are still in the process of "bootstrapping" ourselves. The web application underlying this portal is still to be written. Well, actually one piece is already here: a blogging system running on microsling and CRX. It is this blog that you are currently reading.

Moving forward, we will add a wiki, a mailing list and the other infrastructure you would expect from a developer portal. While this goes on we will blog about our lessons learned, how we do things and, most important, show you the code. So you will be live and on the scene while this portal starts to grow and mature (by the way, there is an RSS feed you can subscribe to).