Sling 是构建网络内容管理系统的革命性一步(转载自dev.day.com)
来源:互联网 发布:windows dhcp服务器 编辑:程序博客网 时间:2024/05/17 02:44
source: http://dev.day.com/microsling/content/blogs/main/evolution.html
Sling is an evolutionary step for WCMSs
filed under cms | posted by Michael Marth
Communique 5 is currently being built on top of Apache Sling. I believe this is a step forward in the overall architectural evolution of web content management systems because it exposes a new type of interface to developers of content centric applications: the web infrastructure layer. Let me explain this idea in the context of CMS history:
1. The Big Blob
Seen from a developer's perspective early CMSs came along as one big piece of software . If you wanted to develop custom applications with them you usually had to develop on top of the CMS API. This API for WCMS would contain abstractions like "paragraph", "user" or "workflow" and expose actions like "publish a page", i.e. the abstraction level was the level of the WCMS business logic (I use the term "business logic" as in "the business of managing content"). For the purpose of this argument, let's call these APIs the "business level API".
2. Splitting off the repository
It was obvious that the content had to be also accessible for developers outside of the context of the business-layer API. Thus, the repository layer was abstracted: a number of CMSs created an API that allowed direct access to the content, either through JCR/JSR-170 or some proprietary API. This gave developers two choices how to access the content: either in the context of the business API or the "raw" access through, say, JCR.
Introducing the repository-level API can be seen as a clean architectural cut for a CMS in order to improve separation of concerns.
3. Splitting off the web infrastructure
In this next evolutionary step we take what is left of the WCMS after the repository is split off and separate off another layer: the web infrastrucure (Sling). This layer contains the basic plumbing required to build web apps, e.g. request handling, selecting content, script execution, authentication, filters etc. This leaves the business layer with the business logic only.
One effect of splitting off the web infrastructure is that developers can write web applications that sit "next to" the WCMS application rather than running on top of the WCMS. This means that these developers do not need to be concerned with (and learn about) the particular CMS business logic because they have access to the web application infrastructure provided by the CMS.
This is a second architectural cut and separation of concerns that acknowledges that there are different types of content centric applications and WCMS is only one of them (consider forums, blogs, media asset management, wikis, etc). These different content-centric apps share requirements for repositories and web infrastructure, though.
It should be noted that compared to the second step above this additional separation of concerns does not really allow you to do anything that was not possible before. However, it is such a big advancement in terms of developer productivity that I consider it to be a qualitative change. (If you disagree: Try building a web app starting with just a connection to your repository and another one on top of Sling. You will understand.)
Some clarifications
There are of course myriads of WCMSs already that let developers write extensions or modules or similar. That approach is different though because these applications run "within" the CMS context, i.e. the developer is still interfacing the business layer. On top of Sling, your app is a first-class citizen just like CQ5.
This CMS-oriented view of the world and its history might seem strange if you look from an application server angle: in the app server world the persistence layer, the application framework (Struts, PHP, ...) and the application were always neatly separated - so Sling would be nothing new. However, this is not quite the same situation as step 3 in the CMS world because in the classical web infrastructure world the application framework knows nothing about the underlying repository - usually it just handles database connection pooling or similar. Sling does know about the repository and thus it can provide additional functionality. Therefore, if you want to stay in the classical web infrastructure picture you could regard Sling as a very specialized application framework (specialized for content-centric applications). AFAIK this is a new piece of infrastructure that did not exist before.
- Sling 是构建网络内容管理系统的革命性一步(转载自dev.day.com)
- (转载)[ZT]内容管理系统(CMS)的设计和选型
- 网吧系统的革命性改变
- 一种革命性的自绘菜单实现
- 构建微服务绝不是单纯的切割模块; 你可知道如何一步, 一步的构建微服务?
- Linux系统中/dev/mtd与/dev/mtdblock的区别(转载)
- 主要的CMS(内容管理系统)提供商
- Joomla 内容管理系统 (CMS)的弱点
- 我的内容管理系统
- 为什么说Flutter是革命性的?
- 网站内容管理系统系列---内容构建
- CMS(内容管理系统)
- 内容管理系统(CMS)
- infoglue(内容管理系统)
- 构建高可扩Web架构和分布式系统实战(下)(转载自CSDN)
- 构建高可扩Web架构和分布式系统实战(下)(转载自CSDN)
- cms系统(内容管理系统)
- 使用sql server分析系统日志(转载自neeao.com)
- SQL Server 2005新特性
- SQLServer和Oracle的常用函数对比
- SQLServer 20005 简化了分页查询以及行做序号功能
- SQL插入表方法总结
- 论设计模式在软件开发中的应用
- Sling 是构建网络内容管理系统的革命性一步(转载自dev.day.com)
- Tomcat域名或IP地址访问方式配置方法
- 浅谈doGet和doPost
- 第一课 搭建Eclipse下Jbpm开发环境
- 第二课 JBPM数据库的构建
- 插曲一 解决-source 1.4 中不支持注释和泛型问题
- 插曲二 转网上介绍的另一篇“JBPM用sqlserver数据库”
- JAVA数据库连接大全
- JBoss Web和 Tomcat的区别