Lots of obituaries lately: Java a few weeks ago, now JCR. CMSWire has a newspost asking if the Java Content Repository specification is dead, that maybe CMIS (Conemtnt Management Interoperability Services) has taken its place.

First off, what JCR is: It's the "Java Content Repository," an API for storing content in a tree. It provides a specific set of capabilities (trees are made of nodes; nodes can have attributes, versions, types, references, and other nodes; queries are by a JCR-specific query language or XPath; this is not a full list).

It's got a fairly steep learning curve, I think. The concepts behind it aren't hard, but the API makes you go through a set of hoops to get everything worked out, it takes a bit to "get it." Plus, like some other APIs java has, it doesn't give you a standard way to acquire a content repository out of the box. (You end up binding to repository-specific constructors, for example.)

So what's this CMIS? It's an interop layer above a content repository, regardless of what the content repository is, managed by OASIS. For example, with CMIS, your app could use a repository hosted in PHP, or some other repository - as an access layer, it's up to CMIS to say "this is how a repository acts" (and its up to the repository to act that way).

It provides the same concepts as JCR (queries, nodes, attributes) so the abstraction means you're not tied to a single or specific repository (different repositories would provide different CMIS urls), the fact that it's service-based means that all you'd need is a URL to get started (fixing the "where do i begin" problem).

If you want to check out CMIS, there's a really good PDF referenced in "Getting started with CMIS."

So is JCR dead, really? Not really - it's just being hidden under a layer that makes it more convenient to work with, to me. What do you think? Have you ever used JCR, or wanted to?

When JCR spec was finalized I spent several weeks reading and studying it. After I read the spec, I studied jack rabbit and looked at some JCR containers. The thing is, JCR was designed to store documents in a tree structure. If the data you want to store fit perfectly within those requirements, then you're good. On the other hand, you need to store x-ray images related to a claim and have the ability to manage and audit it easily, then I would say JCR is wrong. If you want to store an object graph, JCR is not a good fit.

In my mind, JCR was designed to store the contents of a website. I doubt that it will die, but there was too much hype about JCR when it came out.

Peter, then what would be a better way to "store x-ray images related to a claim and have the ability to manage and audit it easily"?

Peter, then what would be a better way to "store x-ray images related to a claim and have the ability to manage and audit it easily"?

The thing is, x-ray images falls under government regulations. That means those images have to be encrypted, since it's sensitive data. The x-ray image is related to the customer, but it is also related to one or more claims. Which means it doesn't fit neatly into a tree structure. The way the data is used is closer to relational than hierarchical. That's just a few reasons why I feel JCR isn't a good fit for this type of use case. I'm sure some one will disagree and try to use JCR like a hammer based on marketing hype.

The reason I mentioned JCR for storing website data, is that's basically a tree structure. Then again, I'm sure there are website that don't fit that model, so it's up to each developer to evaluate.

There's no reason that any of this makes JCR wrong for x-ray images. Encryption is a client-side thing; you'd store a set of bytes, encrypted.

As far as being related to one or more claims, well, that's easy too: if the claims are in JCR as well, then they can contain references to the x-ray, or vice versa. If the claims are in a RDBMS, then the x-ray image in JCR can have an attribute that contains a list of the appropriate claims, which would be easy to use for querying.

I don't know that your wrong, so much as making a decision based on faulty assumptions. On your part.

There's no reason that any of this makes JCR wrong for x-ray images. Encryption is a client-side thing; you'd store a set of bytes, encrypted.

As far as being related to one or more claims, well, that's easy too: if the claims are in JCR as well, then they can contain references to the x-ray, or vice versa. If the claims are in a RDBMS, then the x-ray image in JCR can have an attribute that contains a list of the appropriate claims, which would be easy to use for querying.

I don't know that your wrong, so much as making a decision based on faulty assumptions. On your part.

I agree encryption can be implemented on the client side and usually it's sent over a secure webservice or some other secure channel. The thing is, from what i've seen, it's done on the serverside. There's pros and cons to both methods, so it's a matter of choice. Usually claims aren't stored in a JCR repository. I've seen health, property and casualty insurance and none of them use JCR. Take auto insurance for example, it tends to be full of many-to-many relationships with bi-temporal versioning requirements. If we try to model many-to-many using object modeling techniques it "can" rapidly become a huge head ache. That's from first hand experience. Once we get into things like entity versioning, bi-temporal versioning and many-to-many relations, a tree centric approach doesn't feel like a good fit to me. Of course we could do similar things using JCR, but is that really appropriate or desirable? That's just my opinion from first hand experience

Well, document storage is really meant for data that is irregular, or schemaless. xrays probably wouldn't fit this really strongly, unless you attached attributes to the xrays ('has shinbone, has break, has greenstick fracture"). When you apply schemas to document storage, the documents usually aren't as strong.

Peter, I really want to know what you believe is better, not why JCR is not suitable (or any CR for that matter).  I keep going back and forth on this issue so i am curious as to 1) what better solutions there are 2) why they are better.  

There's this whole area of research into trusted digital repositories and policy-based management.  It's an issue now in archival and scientific data, but I'm really interested in how it fits into the field of 'enterprise' solutions.

Check out www.irods.org

Peter, I really want to know what you believe is better, not why JCR is not suitable (or any CR for that matter).  I keep going back and forth on this issue so i am curious as to 1) what better solutions there are 2) why they are better.  

I'm going to ignore JCR API, since I don't like it. My own preference is to look at the functional requirements. Take for example a business directory that's modeled in an language like Java. Say we start out with a simple classification of businesses by category, subcategory. Over time, we start to relate businesses beyond simple category and subcategory. If I started with a tree centric approach, that means I probably started quering by category and subcategory fields. Once the relations changes to many-to-many relations, I have to change the system to query both the old and new objects on a search. In contrast, if I started with a relational model that isn't hierarchical, it probably will be easier to add more relationships between businesses in a cross reference table. When I need to search, I can reduce the amount of rewriting. Of course this depends on how it's implemented and designed.

The way JCR handles versioning for me makes it inappropriate for bi-temporal versioning. In auto insurance industry, often times there's 2 additional dimensio of temporal versioning: back-dating and branching with entity versioning. So although I "could" in theory bastardize a JCR container to handle quad-temporal versioning, it doesn't make any sense to me. I've spent the last several years working with temporal versioning in different applications, so it's from first hand experience.

If I had a big website that needed to be versioned and maintained, I would consider using JCR. For me, it feels like a good fit for storing stuff files in a "file system" like structure.

Cara Beriklan Di Internet   Puisi Romantis  Puisi Patah Hati  Zodiak  Zodiak Hari Ini  Zodiak Minggu Ini  Contoh Surat Lamaran Kerja  Contoh Proposal

If your application requires the stroring of documents (which incidentally a large number of business applications is about), then JCR is likely the way to go (assuming you are developing on a JVM).   I don't think you want to re-invent the wheel of versioning, security and all the other features JCR provides on top of a relational database.

Now if you are plan on building something else that requires a rich graph or google scale scalability, then consider something else like the NoSQL databases out there.   For everything else, there's the tried and true relational database at your disposal.

It's better than you seem to think it is. Look at InfoQ - it uses Jackrabbit as the backend. At one point, it stood up to slashdotting, and took it well - without a lot of cache stuff to help protect it from load. The access mechanism for data was very strong.

That's typical for JCR. you can use it poorly, sure, and you can do it badly, but in general it's very strong even for regular data. (meaning data that's regular, not "ordinary.")

Can i do a 2 phase commit with CMIS?