Sling forms the basis of the Web Experience Management (WEM/CQ) within Adobe’s ADEP Experience Services. It is robust and makes Web sites easy to develop and then deploy into production. In addition, it has a system for managing digital assets stored within the JCR. ADEP Experience Services implements Sling using its CRX JCR.
In an earlier post I talked about my experience years ago with a content management built on top of a object database called Userland Frontier. Frontier allowed content to be totally separated from the code and HTML used to implement it. That experience has given me a deep appreciation for Web Experience Management.
Within WEM content is not HTML, but the text, photos and other media used as raw material for Web pages. Content is rendered to HTML when needed based on metadata of the content and the context the content is being viewed. If a person views the content from their desktop computer, the content will be rendered for the desktop computer. If another person views that same content from their smart phone, the content will be rendered for the smart phone. The context drives the way content is rendered, but context is not limited to device type. Content can be rendered for women differently than for men. Or it can be rendered differently for a person in one city than for someone in another. Sling makes this smart rendering of content possible and WEM gives the owner of the Web site the tools to use it.
The Experience Services platform is built on top of a Java content repository (JCR). Day Software developed the JCR, CRX, that is in use by Adobe.
The term Java content repository can be used interchangebly for the Content Respository API for Java or for a software implementation of that API. The JCR is at heart an object database, with a hierarchical description of data. The API has standard methods to interact with an object database. It describes methods for importing and exporting data. It describes methods for searching the object database. Defined in the API, also, is data versioning.
Object databases (ODB) are interesting beasts. Most any type of data that is stored within a computer’s file system can be store in one. A Web site, with its whole directory and file structure, could be replicated in one. In addition, code can be stored and called inside an ODB. An ODB can be much more than the computer’s file system. Metadata can be defined for objects and the type of metadata stored can contain anything that the ODB can store.
My first introduction to an object database was with Userland Frontier back in the ’90s. The ODB contained scripts that ran a language called UserTalk. Website management capabilities were added to it and that is what I used it for. I learned the power of the practice of separating content from the code of the implementation. The information for the Website could be stored in the ODB not as HTML pages, but as content. The HTML was defined in separate templates, and the content and HTML code stayed distinct from one another until it came time to deploy. Then the pages would be created and placed online using FTP. A Web server was added to the ODB and Frontier became a content management system. Frontier had a lot of potential, but the company that developed it eventually stopped maintaining it.
The JCR at the core of Experience Services actualizes the potential that Frontier had, plus some. By itself, an object database does not do much. It is the parts that are hung from it that give it power.