Recently, I was looking into implementing Jackrabbit, a java content repository for a project. Based on few days of research ( alrite, I will call it googling next time), I found the concept of JCR very interesting. In a nutshell, when the JCR spec was written a few years ago, it was viewed as a technical solution that will radically change the existing way of application development.
In a typical development environment, we have few major components or layers. One layer is the application layer which has the user interface code and business logic. The second important one is the database layer where we have relational databases which stores data created by the application. In recent years, we also have a third layer sometimes known as framework layer which separates user interface and the business logic, providing the business logic as service.
JCR spec views content repository as an alternative to the database layer in application development. So the developers, instead of thinking in terms of tables, columns and data-type, they are forced to model the application based on content hierarchy in their domain. No more thinking interms of tables, normalisation, columns and more importantly id columns in tables. You design an application, just think interms of content that application deals with and their hierarchy. Thats it. If you need versioning, locking, referencing or access control, dont worry it is provided by the spec. Ok, how about querying. In JCR you can query either via SQL or Xpath. Even better. Alrite, how about deploying? Too easy, you can bundle JCR within your application, deploy it as a resource in your J2EE app server and access it as a resource or deploy it as a server similar to DB server and access it. Too good? One other cool feature is that you can expose the repository as a Web DAV location and user can add content by mapping the location as a folder in their computer. Very good indeed.
Most of the examples I found, points out how easy is to model a blog or a wiki application using a content repository. Inside JCR, the content that is persisted can be stored in file system, XML store, Web DAV repository or a database. I testdrived Jackrabbit by deploying it onto JBoss. The whole process of deploying was so easy and accessing the repository programmatically or via Web DAV was very easy. Fabulous!
Given the cool features of JCR, one would expect that many people adapted it by now. However, I couldn't find that many articles or tutorials or samples on the web. Take hibernate for instance which is a ORM for databases has become very popular since its inception. Its not alone hibernate but the whole ORM paradigm was widely accepted and used in many places. So, why JCR is not as popular as it should be? Based on my few days of experience with JCR, I think lack of ability to access and change the data ( similar to command line access to execute SQL query on a database), browsing tools to view repository data and change in the way to model an application are few of the reasons why Jackrabbit/JCR has not become popular. Or is there any other reason for this? The search begins..
In a typical development environment, we have few major components or layers. One layer is the application layer which has the user interface code and business logic. The second important one is the database layer where we have relational databases which stores data created by the application. In recent years, we also have a third layer sometimes known as framework layer which separates user interface and the business logic, providing the business logic as service.
JCR spec views content repository as an alternative to the database layer in application development. So the developers, instead of thinking in terms of tables, columns and data-type, they are forced to model the application based on content hierarchy in their domain. No more thinking interms of tables, normalisation, columns and more importantly id columns in tables. You design an application, just think interms of content that application deals with and their hierarchy. Thats it. If you need versioning, locking, referencing or access control, dont worry it is provided by the spec. Ok, how about querying. In JCR you can query either via SQL or Xpath. Even better. Alrite, how about deploying? Too easy, you can bundle JCR within your application, deploy it as a resource in your J2EE app server and access it as a resource or deploy it as a server similar to DB server and access it. Too good? One other cool feature is that you can expose the repository as a Web DAV location and user can add content by mapping the location as a folder in their computer. Very good indeed.
Most of the examples I found, points out how easy is to model a blog or a wiki application using a content repository. Inside JCR, the content that is persisted can be stored in file system, XML store, Web DAV repository or a database. I testdrived Jackrabbit by deploying it onto JBoss. The whole process of deploying was so easy and accessing the repository programmatically or via Web DAV was very easy. Fabulous!
Given the cool features of JCR, one would expect that many people adapted it by now. However, I couldn't find that many articles or tutorials or samples on the web. Take hibernate for instance which is a ORM for databases has become very popular since its inception. Its not alone hibernate but the whole ORM paradigm was widely accepted and used in many places. So, why JCR is not as popular as it should be? Based on my few days of experience with JCR, I think lack of ability to access and change the data ( similar to command line access to execute SQL query on a database), browsing tools to view repository data and change in the way to model an application are few of the reasons why Jackrabbit/JCR has not become popular. Or is there any other reason for this? The search begins..
