Latest Posts

Popular Posts [+]

Archives [+]

Categories [+]

Authors [+]

Follow us on Twitter

Composite pages in Apache Sling: Using sling.include( ) http://3.ly/QRNH

Today

#German #Webinar: Enterprise2.0 with CQ5. Register now http://day.com/CQ5Enterprise20 #CMS #Enterprise2.0

5 days ago

RT @trieloff: We improved the chart rendering for bar and line charts in #CQ53 http://bit.ly/azfzBK #featureoftheday

8 days ago

RT @davidnuescheler: Congrats to @rmcveigh / Oracle and Peeter Piegaze / Day to be elected unanimously as Secretary of the #CMIS TC

13 days ago

RT @trieloff: CQ5 DAM's Mosaic Lens allows easy asset browsing http://bit.ly/dxGdLK #featureoftheday #CQ53

13 days ago

Entries filed under 'fud busting'

    Posted by Michael Marth JAN 02, 2008

    Posted in fud busting and jcr Comments 5

    JCR? CR!

    CMSWatch has commented on JCR and how important it is, that content repositories can be accessed through various languages. I wholeheartedly agree. However, they also write:

    But if the API mandates the use of one particular language (such as Java), the Holy Grail of universality immediately takes a hit. Not everyone uses Java, or wants to.

    The API itself does not mandate a particular language (if anything, you might have troubles with type conversions). In fact there are a number of projects for integration of JCRs and other languages.

    Integration of a JSR-170 compliant repository and a language other than Java can come in 3 flavours (that I am aware of):

    1. Implementation of of the API in another language, i.e. implementation of the spec
    2. Accessing a Java-based JSR-170 implementation through an adapter that maps Java and another language
    3. Accessing a Java-based JSR-170 implementation through REST (i.e. http)

    The first route is taken by the open source cms Typo3. In the upcoming version 5 Typo 3 will use its own PHP-based implementation of a JSR-170 compliant content repository. More information about this approach is available here:

    The second approach has been chosen by another popular open source cms: Midgard. While Midgard is written PHP it makes makes its content available through the JCR API. JNI is used for the integration.

    Further examples of this approach are

    • Getting access to a JCR from .Net (C#) has been described here
    • The Java Content Repository Ice Connector allows access to a JCR from C#, VB, C++, Python, PHP.
    • The PHP-Java-Bridge has been used in the Typo 3 project recently to get access to a Java-based JCR from PHP (before the port mentioned above).

    The third way of cross-language access to a JCR is to access the repository via a RESTful API. This is implemented for example in microjax. In microjax the language of choice is Javascript and the data exchange format is JSON.

    Are you aware of other endeavours in this area? Please leave a comment.

    Posted by Michael Marth DEC 06, 2007

    Posted in fud busting and jcr Comments 2

    JCR is not a relig^H^H^H^H^H architecture like SOA

    This morning I came across this post on CMS watch where some alleged implications of using a JCR are discussed. It made me realize again that there are some misconceptions about JCRs out there. So I decided to start a little series of blog posts (with the heroic tag "FUD busting") where I try to shed some light on these misconceptions.

    The part of the CMS watch post that I would like to discuss:

    Gupta's comments weren't aimed specifically at JCR (the Java Content Repository initiative, also known as JSR 170 and now JSR 283), but he speculated that JCR, which effectively hides repositories behind one unified API, could be understood in the context of yet-another-hub-and-spoke-system. His point wasn't that JCR is evil or that abstraction layers aren't good, but that we know content exists in mini-silos all over the network, in heterogeneous systems, under non-centralized control. (And usually for good reasons.) Like it or not, the edges of the network tend to build out organically, resulting in what might be called "accidental architecture."

    The author describes JCR in the context of an enterprise architecture, implying that implementing a JCR would require a certain architecture or that it would prevent certain types of architecture. While he does not explicitly say so, he gives this impression.

    However, JCR does not at all dictate any kind of architecture. There is nothing that says you must have centralized control or similar. It is just an interface. Given the example above with many mini-silos some of them could be JCR repositories and some could not. Why should that be a problem? It might be a hassle due to the different interfaces that must be dealt with, but it is not an architectural problem for JCR.

    So, rather than thinking of JCR in terms of an architecture (like SOA) think of it as an interface (like HTTP). Really convenient to use, but without a penalty if you decide not to use it from time to time.