Integrating JCR into my application

Question

I'm building a JSF-Spring-Hibernate based application which needs to store content as pdf, MS Office files, etc. I was thinking about providing it JCR capabilities, adding Jackrabbit or Modeshape i.e. However I still have some doubts.

• We actually store content as raw files in the File System and add a reference into our MySql database to them. That DB table keeps also info about modifications, versions, etc. Having it like that makes so easy to retrieve data about uploaded files per group, per user, etc. Is this so straight forward using the JCR API? Moreover, is there the possibility of keeping the files as they are in the file system and storing metadata info into MySQL as we're actually doing but using JCR?

• The created by - updated by fields are actually stored in DB table and referred to system users in my application, but JCR implementations seem to have their own authentication system. I supose here the way to go is to create a new user into the JCR implementation per user of the system is created? What about password updates? Is it advisable to keep the user system password synchronized with the one from repository? Or should it be enough using the same password for every single user into the repository?

• We often deal with same documents in more than one language. In this case, the document version is the same, but the language differ between files. I've seen there's a jcr:language property in the specs, can this be used for that?

• Another possible issue I can see is that we're not currently controlling name duplication in our group names for example. There could be two equal group names and to differ their directories into the File System we're using their DB id's appended to the name in the directory path. I don't know if this is really a best practice an how could we manage it with a JCR implementation...

PD: My servlet container is Tomcat 6.

Pool your ideas!

Answer 1

You've stated that you're already relying upon Hibernate and MySQL to store most of your data and storing files on the file system. What are you hoping that JCR might bring to the table? What is it about Hibernate, MySQL, and/or the file system that is not sufficient? Is your current architecture difficult to scale or cluster? Do you having concurrency problems writing the same file? Are your entity classes to restrictive? Do you're entities form a hierarchy, since this is often difficult with Hibernate and a relational database?

There has to be some reason why you'd consider changing your current architecture to add in a whole new data storage technology.

Let's imagine that you would like to just store the file content inside the JCR repository instead of on the file system. Yes, that would work, and it would likely simplify your application a bit and make it easier with less code. But is that benefit worth the complexity of adding in a JCR implementation to your application? (Only you can answer this.)

Or are you also considering using JCR instead of Hibernate. Some find that hard to imagine, but in some cases (especially when your entities are mostly map-like data structures anyway) JCR actually can store information much more cleanly than Hibernate.

Store your data inside JCR means that each "entity" is represented with a node and properties (and possibly child nodes for more complex entities), and that those entities would be stored in a hierarchical structure. You could do all of this while using a generic node type (like nt:unstructured), or you could choose to define a node type for each type of entity. With mixin types and residual property definitions you can even allow the nodes for a single type of entity to vary in the kind of information they hold: all customer nodes might contain a customer ID, first name, last name, and a few other bits of information, but some customers have additional information (membership ID, memberSinceDate, etc.) that you only need to add to the appropriate customer nodes. As your requirements change over time, the data stored on the nodes can easily evolve with it, sometimes without even having to modify your node types (which, BTW, can be done dynamically without restarting your application or if you planned ahead without requiring you to change your application code).

In short, using JCR as a database gives you tremendous amounts of flexibility, even after your application has been developed. It frees you from having to define explicit classes with fixed fields for your data entities, and it allows your application to be more concerned with what information is appropriate for a specific entity instance.

In summary, just using JCR to store the files is probably overkill - it sounds like you've already got entities that store the metadata about the files. The way you describe your architecture, you would not really be benefiting from any of the best features of JCR. That makes me think that JCR is simply not a great fit for your current architecture - you seem to have implemented most of the functionality yourself.