Latest Posts

Archives [+]

Archive for 'April 2008'

    Posted by Lars Trieloff APR 24, 2008

    Posted in sling and tutorial Comments 10

    My recent activity in the Sling community has been centered around SLING-301, an enhancement request that adds Dojo classes to Sling readily available for every application developer. You might ask: “What is so great about Dojo, that it needs to be added to Sling?”. Let me answer this with a short 101 on using Dojo with regard to Sling.

    Dojo is a Javascript framework that can be used for client-side and server-side Javascript programming and will provide a rich programming environment for Javascript programmers providing browser abstractions, a persistent storage API, a Comet client library, a widget library, a template system, a module system that supports lazy loading, a query framework, Javascript language enhancements such as easy class-based inheritance, enhanced for loops and many more. From my personal experience the Dojo Toolkit is a very well-engineered piece of software with good modularization and proper use of abstractions, which might be a reason why large web applications such as Bloglines or AOL webmail are using Dojo as the primary Javascript framework. This use of abstractions and modularizations is what makes Dojo so easily integrateable with Sling.

    As you might know, Sling comes with the Sling client library, a component that allows Javascript developers to access the underlying Java Content Repository by GETting a JSON representation of a node (or a tree of nodes) and POSTing updates to nodes through web forms. While this is convenient if you are developing small applications from scratch, you might want to use an existing Javascript Widget library instead to spare the hassle of implementing all widgets yourself and dealing with browser quirks. This is where Dojo comes into play. Dojo provides a large widget library (called Dijit) that contains components such as Combo-Boxes, Tree Controls or, in the (DojoX package) a complete Grid control that supports column and row spanning, sorting and customizable cell editors. All of these widgets use a modular Store API to access its data model and this Store API is independent of implementation, which allowed me to create specialized Stores that allow accessing the Content Repository in a transparent way. The Store API itself is modular, so there are widgets and stores that only require and provide read access, others have support for write access, others for identity and thus hierarchical storage. The Sling stores provide all of these aspects and can be used for all widgets as a consequence. In order to use the Store API, you have to follow this procedure:

    a) Load the Dojo Bundle using the Sling console
    b) Create an HTML page that imports the Dojo Javascript and CSS files:

     
    <html>
    <head>
      <title>Dojo and Sling</title>
      <style type="text/css">
      @import "../../../dijit/themes/tundra/tundra.css";
      @import "../../../dojo/resources/dojo.css";
      @import "../../../dijit/tests/css/dijitTests.css";
      @import "../../../dojox/grid/_grid/tundraGrid.css";
      </style>
      <script type="text/javascript"
      src="../../../dojo/dojo.js"
      djConfig="isDebug: true,
      parseOnLoad: true, usePlainJson: true"></script>
      <script type="text/javascript">
        dojo.require("dojo.parser");
        dojo.require("dijit.Tree");
        dojo.require("dojox.data.SlingNodeStore");
        dojo.require("dojox.data.SlingPropertyStore");
        dojo.require("dojox.grid._data.model");
      </script>
    </head>
    
    <body class="tundra">
    

    Create the data store. You can do this declarative by using following HTML snippet in your page:

     
    <div dojoType="dojox.data.SlingNodeStore"
    url="/" jsId="nodeStore"></div>
    

    Use the Data store, for instance in a Tree widget. Please note the query attribute of the div, which will take care that the tree only shows nodes with a primary type of either nt:folder or nt:file, making it a poor man’s file browser.

     
     <div dojoType="dijit.Tree"
      id="tree1" store="nodeStore"
      query="{ query: { 'jcr:primaryType' : ['nt:folder',
      'rep:root'] } }">
      </div>
     

    If you would like to learn more about Dojo, head to the Dojo homepage and do not forget to take a look at the Dojo Feature Explorer provided by Dojo Campus, a blog providing well written tutorials on various aspects of Dojo.

    Posted by Michael Marth APR 24, 2008

    Posted in sling Comment 1

    The Apache Sling project has won a prize at the JAX Innovation Award, see Carsten Ziegeler's blog post about the ceremony. Congratulations to the Sling development team.

    Happy Sling developers Felix Meschberger and Carsten Ziegeler

    Posted by Michael Marth APR 23, 2008

    Posted in dynamic languages and sling Add comment

    Today the Google Summer of Code program has announced the accepted students for this year. There is one JCR-related project that got through: Janandith will work on integrating Sling and Scala. The mentor is Day's Bertrand Delacretaz (with a little help from Michael Dürig, who also wrote some posts on Scala and JCR on dev.day.com).

    Posted by Michael Marth APR 23, 2008

    Posted in apache Add comment

    If you are (like me) interested in Roy T. Fielding's new protocol waka make sure you do not miss his presentation on Apache's HTTP Server 3.0 that is now embedded in this post.

    Posted by Michael Marth APR 18, 2008

    Posted in crx quickstart, data first, davids model, everything is content, graph, jcr, open, rest, sling, social and tutorial Comments 4

    In case you follow emerging Internet standards you will have come across OpenSocial, the Google-led spec for social network applications. Major supporters are MySpace, LinkedIn, XING, Google's own Orkut, Hi5 and others. The Apache Software Foundation's implementation of this spec is called Apache Shindig. It is a container (runtime) for OpenSocial applications (which are called gadgets).

    In my opinion OpenSocial and Apache Sling are a good technical fit for at least two reasons:

    1. On a raw technology level both use the same technology building blocks, e.g. JavaScript: in Sling JS is used on the server-side for .esp templates and on the client-side in the case of JST templates. OpenSocial gadgets are coded in JS as well. Moreover, associated technologies like JSON, feeds and REST are supported by both.
    2. On a more conceptional level: As a spec that must work across a number of different social networks the majority of information that is accessible through the OpenSocial API is optional, i.e. it is up to the container if data is returned or not. This situation is a good fit to the unstructured, "Data First" approach that is enabled by Sling (respectively the underlying JCR).

    I would like to show Apache Shindig (Apache's OpenSocial container implementation) and CRX Quickstart (a bundle of Apache Sling and Day's JCR-compliant repository) working together in this blog post.

    Installation

    In this screencast I have shown how to install CRX Quickstart: double-click on its icon (CRX Quickstart is not available, yet, but it will be very soon). Strictly speaking, you do not need CRX Quickstart for the examples below. It all works with "plain" Sling as well.

    Installing Shindig is a tad more complicated and described on Shindig's web site. You need to check out, do a Maven build (I used revision 648157 for this example) and start Shindig's Jetty server on port 8080 with:

    mvn jetty:run-war

    Once you started Shindig hit /gadgets/files/samplecontainer/samplecontainer.html on http://localhost:8080. You should get a kind of gadget console that looks like this (click to enlarge):

     

    Shindig comes with an example implementation of a social network. By default it runs the "Hello World" example gadget located at:/gadgets/files/samplecontainer/examples/SocialHelloWorld.xml on http://localhost:8080.(btw Shindig comes with some example data so don't worry, if you have no friends - Shindig has some imaginary ones for you).

    Friends are Content

    What I would like do is: grab the gadget's viewer's friends and all the available data about them and store this data in the repository. For this purpose I have written a little gadget (see below) and saved it in my JCR repository at /apps/friends/friendsaver.html. By default the repository is running on port 7402, so when I point the gadget console to http://localhost:7402/apps/friends/friendsaver.html I get (click to enlarge):

     

    The gadget retrieves the viewer's friends and displays them in HTML. Moreover, in the background the viewer's data and the available friend data is posted to my repository. In the Content Explorer this looks like (click to enlarge):

     

    Hey, remember the "Everything is Content" mantra? Well, your imaginary friends are content, too.

    Please note that this works without setting up any schema or any other configuration of the repository. I ran it on an out-of-the-box CRX Quickstart (see also this screencast and this post about Data First). Only for the fields that are actually sent node properties are created.

    The Gadget Code

    The gadget is completely standard OpenSocial code, no surprises here. In onLoadFriends() the viewer's friends (variable viewerFriends) are iterated and displayed in HTML. For each opensocial.Person object the function createFriendNode() is called. In this function an HTTP POST request is sent to the repository that persists the person. Available opensocial.Person.Field data is sent as POST parameters (in the code only gender and first phone number are implemented) and thus persisted as node properties. I want to leverage the repository's hierarchy and store the friends as child nodes below the viewer (see David's model, rule 2). Here's the relevant snippet:

     /**  * Request for friend information.  */function getData() {      var req = opensocial.newDataRequest();  req.add(req.newFetchPersonRequest(opensocial.    DataRequest.PersonId.VIEWER), 'viewer');  req.add(req.newFetchPeopleRequest(opensocial.    DataRequest.Group.VIEWER_FRIENDS),    'viewerFriends');  req.send(onLoadFriends);}; /**  * Parses the response to the friend request  * @param {Object} dataResponse Friend      information that was requested.  */function onLoadFriends(dataResponse) {  var viewer = dataResponse.get('viewer').    getData();  var html = 'Friends of ' + viewer.    getDisplayName();   html += ':<br><ul>';  createFriendNode(viewer);  var viewerFriends = dataResponse.    get('viewerFriends').getData();  viewerFriends.each(function(person) {    html += '<li>'      + person.getDisplayName()      + '</li>';    createFriendNode(person, viewer);  });  html += '</ul>';  document.getElementById('message').    innerHTML = html;};  function createFriendNode(person, parent) {     var url = "http://localhost:7402/content/friends/";  if(parent) {    url += sanitizeId(parent.getId())+"/*";     } else {     url += "*";    }        var params = {};    params[gadgets.io.    RequestParameters.CONTENT_TYPE] =    gadgets.io.ContentType.TEXT;    params[gadgets.io.    RequestParameters.METHOD] =    gadgets.io.MethodType.POST;    var postParams = "";  postParams += 'name=' +    sanitizeId(person.getId()) + '&fullname=' +    person.getDisplayName();  if(person.getField(opensocial.Person.Field.    PHONE_NUMBERS)) postParams +=    ('&phone=' +    person.getField(opensocial.Person.Field.    PHONE_NUMBERS)[0].    getField(opensocial.Phone.Field.NUMBER))  if(person.getField(opensocial.Person.Field.    GENDER)) postParams += ('&gender=' +    person.getField(opensocial.Person.Field.    GENDER).getKey())  // I could add more fields here...        params[gadgets.io.RequestParameters.    POST_DATA] = postParams  gadgets.io.makeRequest(url, null, params);};    function sanitizeId(id) {  return id.replace(".", "_");   }gadgets.util.registerOnLoadHandler(getData);  

    Round-Tripping

    Now that the friends are stored in the repository each one has a URL. Displaying a friend in a simple HTML page can be done with e.g. server-side Javascript. Storing this file in the repository in /apps/friends/html.esp

    <html>  <body>    <h1><%= currentNode["fullname"] %></h1><ul><li>gender: <%= currentNode["gender"] %></li><li>phone: <%= currentNode["phone"] %></li></ul>  </body></html>

    will yield for the URL http://localhost:7402/content/friends/john_doe/jane_doe.html

    But this is only half the fun. It is much more interesting to retrieve the friends data in another OpenSocial gadget. This can easily be done without any repository-side code as Sling natively supports the json format. For example the URL http://localhost:7402/content/friends/john_doe/jane_doe.json will return this node in json format. Like that, we can easily access the friends nodes through a gadget containing this snippet:

    function makeCRXRequest() {    var params = {};    params[gadgets.io.RequestParameters.    CONTENT_TYPE] =    gadgets.io.ContentType.JSON;    var url =    "http://localhost:7402/content/friends/john_doe/"+    document.getElementById("person_name").value+    ".json";    gadgets.io.makeRequest(url, response, params);};function response(person) {    var html = "";  html += "name: " + person.data.fullname +    "<br/>";  html += "phone: " + person.data.phone +     "<br/>";  html += "gender: " + person.data.gender +    "<br/>";    document.getElementById('content_div').     innerHTML = html;};

    The gadget in action looks like this (click to enlarge)

     

    This little hack could be the starting point for a cross-social network phone book application.

    Final remarks

    I hope I could show that Sling and Shindig go really well together. Especially, being able to utilize the JCR repository as a backend without any coding on the repository side looks tempting to me. Maybe at one point Sling will even be able to run OpenSocial gadgets natively.

    In this post I concentrated on frontend intergration technologies. But OpenSocial will soon add a REST API next to its JS API. For Shindig the implementation of this REST API is likely to be Apache Abdera which uses JCR as an optional persistence storage. So there will be additional points of contact.

    Posted by Michael Marth APR 18, 2008

    Posted in sling Add comment

    Out of 38 proposals Apache Sling (the RESTful framework for JCR-backed web apps) has been nominated for the JAX Innovation Award. The winners will be announced and awarded during the JAX Enterprise Architektur Konferenz in Wiesbaden.

    Congratulations and good luck to the Sling team development team!

    Posted by Michael Marth APR 16, 2008

    Posted in cms and jcr Add comment

    About a year ago Pascal Schrafl has published an excellent thesis on content repositories (I came across it only recently). It is based on a questionnaire that was sent out to IT decision-makers. Among the more surprising findings:

    A second major objective of the survey was to determine whether CMS is more important for unstructured information (documents, web pages, e-mails, etc.) than for structured data such as financial data and similar database-type information. Surprisingly, it was not.

    Pascal was so kind to give permission to publish the executive summary of his findings. Please find them below (click the upper right icon for a larger view).


    Read this doc on Scribd: survey-summary
    Content Repository Report Survey Summary Survey Results for the Survey Concerning Standards for Enterprise Content Management Author: Pascal Schra? Bachelor of Arts (Honours) Multimedia Web: www.contentrepositoryreport.com Email: info@contentrepositoryreport.com Contents 1. Note to the Reader 2. Executive Summary 3. Survey Results 3.1. Usage of Content Management Systems . . . . . . . . 3.2. Number of Content Management Systems . . . . . . . 3.3. Solutions to Interoperability Issues . . . . . . . . . . . 3.4. Important Functions of Content Management Systems 3.5. Standards in General . . . . . . . . . . . . . . . . . . . 3.6. Importance of Java in the Enterprise Application Field 3.7. API vs. Protocols . . . . . . . . . . . . . . . . . . . . 3.8. JSR-170 vs. iECM . . . . . . . . . . . . . . . . . . . . 4. Conclusion A. List of Abbreviations B. Copyright 1 2 3 3 3 4 5 7 8 9 9 12 13 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Note to the Reader Dear IT Decision-Maker, This is a summary of the IT survey questionnaire you answered on the Internet sometime during the ?rst three weeks of March 2007. We are grateful for your participation. The survey was one of three research tools used to evaluate the options available to IT decisionmakers for the purpose of managing the digital content that seems to be exploding in volume for all of our enterprises. A special focus of the study was what is called unstructured content, such as documents, reports, graphics, and website pages, which does not lend itself to being kept in databases. It is this unstructured content that is growing exponentially. What options are currently available to IT decision-makers for handling this type of content? What parameters for handling it are important to you as a decision-maker? How important are platforms, languages, licensing fees, and standards? Another focus of the research has to do with accessing the various systems holding information in proprietary formats. How much of a problem is this for you? What options are you aware of for dealing with it? How would you evaluate these various options? Another of the research tools we used for this study was an in-depth review of the information available on the ?ve primary contenders for addressing these problems. Essential information was extracted and organized for comparison purposes for 1. Database Abstraction Layers 2. WebDAV 3. JSR-170 (Java Content Repository API) 4. Web Services 5. SOA and iECM Our third approach was to do an in-depth interview with David N¨scheler, the leader of u the JSR-170 initiative (and CTO of Day Software AG in Basel), to gain his perspective on the various options. Mr. N¨scheler gave us an objective and impartial overview, and u made predictions concerning roadblocks for the SOA and iECM standards process that have already come dramatically true. Our intent with this research is to provide you, as an IT decision-maker, with all of the perspectives and information you will need to make informed choices concerning content management systems in the foreseeable future. The full report, which will be released in November 2007, is available for a very reasonable cost. You can place your reservation using the online reservation form on the Content Repository Report Website at www.contentrepositoryreport.com. Here then is the summary of ?ndings from the Internet survey. Thank you again for your participation. If you have any questions, please don’t hesitate to contact me at info@contentrepositoryreport.com With best regards, Pascal Schra? 1 2. Executive Summary The results of the survey, conducted during March of 2007, highlight that IT decision-makers would most like to adopt standards if they are open and under free licensing. The standardization process itself is perceived as an important factor in the acceptance of the standard; and open, public and free standardization processes are preferred. Supporting the need for standards is the fact that CMS clients with more than six CMS applications are trying to keep the number of CMS vendors low, in order to achieve interoperability by either using custom connectors or purchasing di?erent CMS applications from the same vendor, hoping to reduce the lack of interoperability by supporting proprietary standards. That this tactic is only a temporary solution is shown by the fact that the vast majority of respondents would prefer to use non-proprietary standards, if they are available. Surprising is the result that the management of structured data is perceived as the most important function of a CMS application, which can lead to the conclusion that IT decisionmakers perhaps see no way at present to e?ectively store or manage unstructured data in a standardized manner. The Java programming language is perceived as an important player in the enterprise application ?eld and its platform independence is an important factor in selecting Java. In general, the programming language is not regarded as important for a standard, as long as there are many implementations of the standard in di?erent programming languages. The broad support of standards by many di?erent applications is rated as important, and can be seen as an important factor in preferring older, but well established and supported standards, as is the case with WebDAV. New standards are partially favored, as they are more up-to-date, a trend that would speak against relying solely on WebDAV. A negative in?uence on the decision concerning WebDAV is the fact that IT decision-makers appear to believe that their programmers would have better success with an API standard than with a protocol standard, which requires more programming skills and a deeper knowledge of the internal commands of the protocol, as there is no API layer to capsulate and abstract the protocol layer from the programmer. There was a statistically nonsigni?cant preference for iECM/SOA over JCR, which we will explore in the following summary, but the preference must be regarded as provisional, since the iECM/SOA standard has not yet reached the draft state. 2 3. Survey Results The purpose of the survey was to ascertain how IT decision-makers value content management standards in general and how they would compare particular standards, such as JCR, WebDAV and iECM. David N¨scheler, one of the key ?gures in the CMS standardization process, u says that no research has yet been done in comparing IT decision-maker attitudes towards JCR, WebDAV, and iECM. This survey is therefore the ?rst of its kind. As participants in the survey, you are the ?rst group to learn the results. 3.1. Usage of Content Management Systems The initial questions collected basic information about the systems already in place: 1. Does your organization have a content management system? 2. How many di?erent applications from the content management systems ?eld does your organization have? 3. How many vendors do you have for your di?erent content related applications? The number of content management systems is addressed in question 1. As apparent in Figure 1, 58% of the respondents have several systems in use, 33% have one system, only 3% have no CMS system at all, and 6% are planning a CMS system. Therefore, 91% of the respondents have at least one CMS system currently in use. 2.7% 6.3% Several CMS-Systems One CMS-System 57.7% No CMS-System Planning a CMS-System 33.3% Figure 1: Percentage values of the number CMS systems in use. Total respondents: 112, Valid: 111, Missing: 1. Source: Pascal Schra?, 2007 3.2. Number of Content Management Systems The next two questions (Questions 2 and 3) assess the number of CMS applications and the number of CMS application vendors. 3 Analyzing the results presented in Figure 2, it appears astonishing that there are more vendors in the ?rst two categories (one CMS application/one vendor and two to ?ve CMS applications and the same range of vendors) than there are in companies with more than ?ve applications. 70 60 50 Percent 40 30 20 10 0 1 2-5 6-10 11-15 16-20 Number of Applications / Vendors > 20 70 60 50 40 30 20 10 0 Applications Vendors Figure 2: Percentage values of CMS applications vs. CMS vendors. Total respondents: 94, Valid: 94, Missing: 0. Source: Pascal Schra?, 2007 It appears that organizations with 1-5 CMS applications prefer to have about the same number of vendors for their applications, whereas organizations with 6 or more applications prefer to minimize the number of vendors. This conclusion may be consistent with the exponential growth of connectors or APIs necessary to combine di?erent systems. It also appears that interoperability among systems becomes a critical concern after about ?ve systems are in place, with the result that companies then tend to greatly reduce the number of vendors with which they do CMS business. But is this the preferred solution to the problem of interoperability, or merely a stopgap measure? Question 5 sought to ?nd the answer. 3.3. Solutions to Interoperability Issues 5. Please rank the following solutions to achieve interoperability between content management systems by priority: • Use content management systems from one vendor only. • Use a custom connector for every individual content management system that needs to be connected. • Prefer content management systems that have adopted standards for interoperability. As evident in Figure 3, as a group you prefer the support of standards for interoperability, as 80% ranked this solution with the highest priority. 53% of the participants rank the use of 4 custom connectors as the second best solution, and in the third and last position, with 47%, is the tactic of purchasing all systems from a single vendor. 90 80 70 60 Percent 50 40 30 20 10 0 1 2 Ranking 3 90 80 70 60 50 40 30 20 10 0 Prefer CMS-Applications that support Standards for Interoperability Purchase all CMS-Applications from only one vendor Custom Connector Figure 3: Ranking of solutions to overcome the lack of interoperability. Total respondents: 112, Valid: 112, Missing: 0. Source: Pascal Schra?, 2007 This leads to the conclusion that IT decision-makers would prefer CMS applications that support standards for interoperability over implementing custom connectors or even purchasing their CMS applications from only one vendor. CMS clients appear to have found a temporary solution by reducing the number of CMS vendors, but would prefer standards for addressing the interoperability issue. 3.4. Important Functions of Content Management Systems A second major objective of the survey was to determine whether CMS is more important for unstructured information (documents, web pages, e-mails, etc.) than for structured data such as ?nancial data and similar database-type information. Surprisingly, it was not. The management of structured data is already solved by using ERP systems, but according to many experts, only 10% to 20% of an organization’s data is structured, whereas 80% to 90% of the data is of the unstructured type, and needs to be managed in a di?erent way from structured data, by using ECM systems. As many organizations are doubling their unstructured data every two months, the management of unstructured data should have the highest priority in an organization and should re?ect itself in being the most important feature of a CMS application, especially as in many industries, ERP systems have become standard practice and the management of structured data has become routine. 4. Please rank the following characteristics of a content management system by importance: • Content Management Systems must be able to manage structured data. • Content Management Systems must be able to manage unstructured data. • Exchanging data between di?erent content management systems must be supported. • Legacy systems must be integrated. 5 • Interoperability between di?erent content management systems must be supported. • Being able to use data from di?erent content management systems must be supported. 60 50 40 Percent 30 20 10 0 1 2 3 Ranking Manage Structured Data Manage Unstructured Data Support for Data Exchange between different CMS-Applications Integration of Legacy Systems Support Interoperability Support usage of Data from different CMS-Systems 60 50 40 30 20 10 0 4 5 6 Figure 4: Ranking of the most important features of a CMS application. Total respondents: 112, Valid: 112, Missing: 0. Source: Pascal Schra?, 2007 Figure 4 reveals that the most important feature of a CMS application is the management of structured data (52%). The second most important feature is the management of unstructured data (33%). Third place goes to supporting data exchange between di?erent CMS applications (28%), and the fourth most important features are integrating legacy systems and supporting interoperability, both ranked in the same position (28%). The least important feature is support for using data from di?erent data sources (30%). In contrast to expectation, respondents viewed the most important use of their CMS systems not as the management of unstructured data but the management of structured data, a functionality which, according to many ECM experts, should be already delivered by databases and ERP systems. Nevertheless, the management of unstructured data ranks in the second position, appearing to be important to IT decision-makers. A second anomaly is the low ranking of support for data exchange and the support for using data from di?erent systems. The suggestion that a primary value of ECM is the aggregation of data from di?erent systems to broaden the organization’s knowledge base (unlocking the enterprise content by breaking out of so-called content silos) can only be partially veri?ed, as this does not seem to be one of the most important functions attributed to a CMS system, at least at this point in time. It appears, then, that the management of structured data is regarded by participating IT decision-makers as the most important function of their CMS systems. This result may be interpreted in a couple of ways. First, IT decision-makers may perceive the management of structured data as more important than the management of unstructured data because the 6 CMS applications in use in their organizations only work with structured data, as databases are used to store the content. Alternatively, there could be a knowledge gap between the aims of CMS vendors and CMS clients, which would be need to overcome by better communicating the bene?ts of managing unstructured data. 3.5. Standards in General Returning to the question of standards, IT decision-makers clearly favor open free standards above all others (Question 6). Concerning the standardization process (Question 7), a free and open process, involving all parties and allowing public access to the standardization documents is preferred. Neither the JCP process nor the iECM process is completely open, but this seems to be an important factor for IT decision-makers and should be considered by the speci?cation leads. Question 6, for example, asked you to: Rank the following characteristics of standards according to your preference. • Proprietary standards. • Open standards without license fees. • Open standards with Reasonable and Non Discriminatory Licensing (RAND) fees. • Standards requiring license fees. 90 80 70 60 Percent 50 40 30 20 10 0 1 2 Ranking 3 4 90 80 70 60 50 40 30 20 10 0 Standards requiring License Fees Open Standards with RAND License Open Standards without License Fees Proprietary Standards Figure 5: Frequency expressed in percentage values of four di?erent standards and license schemes. Total respondents: 112, Valid: 112, Missing: 0. Source: Pascal Schra?, 2007 Figure 5 presents the frequency of the four rankings of the di?erent standards and licensing schemes. Clearly visible with 80% is the open and license-free standards scheme. The second most preferred is open standards with reasonable and non-discriminatory (RAND) licensing (71%). The last two positions are not as evident as the previous two, but standards requiring license fees and proprietary standards are the least preferred by participating IT decisionmakers. 7 3.6. Importance of Java in the Enterprise Application Field We turn next to the question of individual standards, beginning with JCR. Question 8 asked you to rate certain statements about Java as a programming language and its importance in the enterprise application ?eld. Figure 6 below graphs the frequency of the answers, and highlights that the Java programming language has a strong acceptance in the ?eld of enterprise applications (30% absolutely agree, 47% agree, for a total of 77%). While there was a ?rm conviction that a standard completely restricted to Java would not succeed, especially according to respondents whose organizations use other programming languages, the JCR standard has already been ported to many other programming languages. Also, more than half of the IT decision-makers do not perceive the programming language of a standard as important, so long as the standard is implemented in many di?erent languages. Figure 6 also displays that Java seems to be an important programming language in the enterprise application ?eld, as other programming languages do not ?nd a high acceptance in the Content Management ?eld. 50 45 40 35 Percent 30 25 20 15 10 5 0 Absolutely agree Partly agree Agree Disagree Totally disagree 50 45 40 35 30 25 20 15 10 5 0 Programming language of a standard is not important, so long as there are many implementations in different programming languages Java is not important, as we use other programming languages Java is important, as it offers platform independence A Java-only standard cannot prevail, as it is tied to the programming language Figure 6: Percentage values of the importance of the Java programming language in the Enterprise Application ?eld. Total respondents: 112, Valid: 112, Missing: 0. Source: Pascal Schra?, 2007 To conclude our ?ndings in this area, the results clearly show that Java is an important player in the ?eld of enterprise applications, as it o?ers platform-independence. Neither the Java-supporters nor the supporters of other programming languages appear to care much about the programming language of a standard, as long as there are many implementations of the standard in di?erent programming languages, so that the standard can be used within their own organization. 8 3.7. API vs. Protocols A related question was raised concerning how much di?erence you as IT decision-makers perceive between protocols and APIs. The reason for this question (see question 9) is that some experts in the ?eld perceive application programming interfaces (such as JSR-170) to be stronger or easier to work with than protocols (such as WebDAV). As it turns out, the ?nal numbers showed only a very weak agreement (see Figure 7). Further statistical analysis, however, revealed that there were actually two sets of much stronger preferences at work, o?setting each other: one group that prefers APIs and another that prefers protocols. To a certain extent, these preferences correlated with favoring older, well-established standards (such as the WebDAV protocol) on the one hand, and favoring newer standards (such as the JCR API) on the other. 60 50 40 Percent 30 20 10 0 Absolutely agree Agree 60 50 40 30 20 10 0 Partly agree Disagree Totally disagree Programmers only use APIs Programmers use the protocol Programmers use the API WebDAV is supported by many applications and should therefore be preferred Older, established standards should be preferred as their implementation is more mature New standards should be preferred, as they are up to date Figure 7: Percentage values for APIs vs. Protocols and new standards vs. older, established standards. Total respondents: 112, Valid: 112, Missing: 0. Source: Pascal Schra?, 2007 A second important tendency can be spotted, as the broad support of a standard by many applications seems to be an important factor in favoring a standard. This result is especially important as it leads to the conclusion that the JSR-170 committee must promote their standard and seek to have it supported by many applications, which in fact has happened. For iECM, the other primary contender for ECM standard, this may be a major obstacle, as the iECM committee, after more than two years of development time, has currently no implementation at all. 3.8. JSR-170 vs. iECM The next question of the survey asked you to evaluate several statements concerning the two primary candidates for a new Content Management standard: JCR and iECM. The full report provides detailed reasoning, but in brief, the other three original candidates were either demoted or combined. First, DBALs were eliminated because database systems are poorly suited for handling unstructured content such as documents and web pages. WebDAV is a very good adjunct to either JCR or iECM for Content Management, but was not 9 designed to convert all of an enterprise’s content from largely unavailable to readily accessible. WebDAV was designed rather to handle individual documents on an as-needed basis. Web Services, which are as compatible with JCR as with iECM, do not by themselves o?er a uni?ed approach to content management. Instead, Web Services would be utilized by Service Oriented Architecture (SOA) in order to access content from di?erent systems. The SOA concept, which is very popular right now, is the primary toolkit of iECM. This leaves us with JCR and iECM as the primary contenders, and the process of elimination just described provided the backdrop for asking you to evaluate several statements concerning these two ?nalists. While no strong preference appeared for either of these two standards, there was a slight preference for SOA-based standards due to their language independence and the ability to use the standard with service-enabled applications. Part of this preference may derive from the fact that API standards involve programming, while SOA is being promoted as a technology that involves minimal or no programming. Statistical analysis showed that four of the responses best capture the very slight tendency in favor of iECM/SOA. These four statements are: 1. A standard based on a service-oriented architecture can be used by all applications that are service-enabled. 2. A standard should not depend on a programming language. 3. Standards based on a service-oriented architecture should be favored above all other standards. 4. The top-down approach of a service-oriented architecture is to be favored above the bottom-up approach of an API. The above mentioned four items were combined into a new synthetic variable, called pro iECM and were tested against the pro JCR items, leading to the slightly positive tendency towards iECM as evident in Figure 8 below. The mean value of 2.42 for the pro iECM variable is marked in yellow. As smaller numbers represent a higher level of agreement, the slight trend towards iECM is visible. 10 18 16 14 12 Frequency 10 8 6 4 2 0 1,00 1,25 1,50 1,75 2,00 2,25 2,50 2,75 3,00 3,25 3,50 3,75 4,00 4,25 4,50 18 16 14 12 10 8 6 4 2 0 Figure 8: Histogram of the pro iECM variable. Mean: 2,4196. As smaller numbers represent a higher level of agreement, the slight trend towards iECM is visible. Total respondents: 112, Valid: 84, Missing: 28. Source: Pascal Schra?, 2007 11 4. Conclusion This report would be incomplete if we did not mention something not known by anyone at the time of the survey, which is that the standards process for iECM/SOA has stalled. The group’s deliberations have since been suspended, apparently because of the extreme di?culty of determining a viable standard in this complex area. The suspension e?ectively leaves JCR (as JSR-170 and its later version, JSR-283) as the only currently viable standard for delivering on the promise of Content Management, which is to make unstructured content as manageable and useful as structured database content is today. 12 A. List of Abbreviations API CMS DAV DBAL ECM ERP iECM JCP JCR JSR SOA WebDAV Application Programming Interface Content Management System Distributed Authoring and Versioning Database Abstraction Layer Enterprise Content Management Enterprise Resource Planning Interoperable ECM Standard Java Community Process Java Content Repository Java Speci?cation Request Service-Oriented Architectures Web-based Distributed Authoring and Versioning 13 B. Copyright Copyright c 2007 by Pascal Schra?. All rights reserved. This document, Results of the Internet Survey of IT Decision-makers, is copyrighted by the author, Pascal Schra? of Maur, Switzerland. The recipient of this special report may download, copy, or print the contents for personal use, provided that the recipient observes all copyright restrictions. Except for personal use, no copying, storage, redistribution, selling, broadcasting, circulating, commercial exploit or publication of this document, in part or in whole, is permitted without the express written consent of the author, Pascal Schra?. In no event will the author or other persons transmitting the information of research reports be liable to you or anyone else for any consequential, incidential, special or indirect damages (including, but not limited to, lost pro?ts, trading losses, and damages that may result from the use of the information or the research reports or from inconvenience, delay or loss of use of information or research reports or for omissions or inaccuracies in the information or the research reports) even if advised the possibility of such damages and, as a condition to accessing such information or research reports, you expressly waive any claim you may have against the author or any other person with respect to any information or research report. There is no warranty of merchantability, no warranty of ?tness for a particular use, and no warranty of non-infringement. There is no warranty of any kind, express or implied, regarding the information of the research reports. The author may be contacted by email at info@contentrepositoryreport.com The Content Repository Report website can be found at http://www.contentrepositoryreport.com 14


    Posted by Michael Marth APR 16, 2008

    Posted in apache, jcr and open Comments 2

    A number of Day employees gave talks at this year's ApacheCon EU in Amsterdam. The topics included Open Source tools, JCR and Apache. In case you could not "enjoy your Day " over there take comfort in the presentation slides:

    Bertrand Delacretaz: Open Source Collaboration Tools are Good For You!

    Looking at how successful Open Source project teams work, one sees the importance of using the right collaboration tools in the right way. How does this translate to your in-house teams? Based on the distributed collaboration model used by the ASF projects, we have defined requirements for a set of collaboration tools, ranked according to their effect on the team's efficiency. Based on this analysis, we propose a migration path, for teams that need to move from an "ask around the office" development model to the efficient "distributed self service information" model used by the ASF and other Open Source organizations. Embracing the ASF way, in small steps if needed, might make a big difference in your programming teams efficiency, and in the quality of their work. Our analyis will help you estimate the effort and expected benefits of such a move.



    Bertrand Delacretaz: JCR Meetup - Slide in 18 Minutes



    Carsten Ziegeler: JCR in Action - Content-based Applications with Apache Jackrabbit

    The Java Content Repository API (JCR) is the ideal solution to store hierarchical structured content and develop content-oriented applications. To demonstrate the basic architecture of such applications, an example content management application will be developed during the session. Basic techniques will be explained including navigation, searching and observations by using the Apache Jackrabbit project.



    Carsten Ziegeler: Maven SCR Plugin

    The SCR plugin for Maven from the Apache Felix project is a simple but powerful tool. In just 15min you'll learn how to develop services in Java to be used in an OSGi environment and how to package and deploy them. You should have knowledge about component oriented development for Java; the talk will also cover the bare minimum OSGi knowledge, but this is not an OSGi introduction.



    Jukka Zitting: File system on Steroids – an Introduction to JCR

    Need a file system with embedded metadata, full text search, and transaction support? Or a database with hierarchies, flexible schemas, and versioning? Take a look at the JCR standard that gives you a rich hierarchical content model with features like structured and unstructured content, full text search, versioning, transactions, and observation. This presentation introduces you to the JCR API and Apache Jackrabbit, the fully featured Apache implementation of JCR.



    Jukka Zitting: Fast Feather Track - MIME Magic with Apache Tika



    Jukka Zitting: JCR Meetup - Jackrabbit roadmap



    Jukka Zitting: JCR Meetup - Design and Architecture of Apache Jackrabbit



    Roy T. Fielding: KEYNOTE: Apache 3.0 (a tall tale)

    Thirteen years ago, the Apache Group founders finished the first beta release of Apache httpd, having reached the end of their initial pile of small improvements, and began to look forward to a complete rewrite of the server architecture. Suddenly, our forward progress slowed to a trickle, mailing list traffic dropped by two-thirds, and our focus diverged.

    The small steps of group collaboration were useless for crossing such a chasm of design. Were it not for an individual leap by Robert Thau, the project would have surely died a slow death of mediocrity. Likewise, were it not for a willingness of the group to accept and admire individual leaps, the new design would have died a slow death of neglect.

    Today, we face a new chasm, and our past successes have only made it wider and deeper than before. This talk is about the other side.



    Roy T. Fielding: A Little REST and Relaxation

    Representational State Transfer (REST) is an architectural style that I developed while improving the core Web protocols (URI, HTTP, and HTML) and leading them through the IETF standardization process. I later described REST as the primary example in my dissertation. Since then, REST has been used (and sometimes abused) by many people throughout the world as a source of guidance for Web application design. But is the REST that we hear about today the same as what I defined in my dissertation, or has it taken on the baggage that comes with an industry buzzword? This talk will provide a real introduction to REST and the design goals behind its evolution as the Web's arhitectural style. This is not about XML-over-HTTP as an alternative to SOAP, nor about "resource-oriented" frameworks that help simplify CRUD operations, but rather about the design goals and trade-offs that influence the development of network-based applications. I will also describe what happens when we relax some of the REST constraints, and how such relaxation is impacting the design of the waka protocol as a replacement for HTTP.



    Posted by Peter Klassen APR 16, 2008

    Posted in cms and communique Add comment

    A lot of corporations follow the trend to unify user interfaces through the SAP Netweaver Enterprise Portal, where all legacy systems, new business applications and external applications can be integrated and personalized. To facilitate this integration we have implemented the SAP-certified Portal Adapter, that enables the integration of CQ functionalities into the SAP Enterprise Portal.

    SAP-integrated CQ functions are:

    • Display and modify CQ content in SAP portlets
    • Portal navigation structure integration
    • CQ's navigation in portlets, combined with other portlets via inter-portlet communication
    • Personalized workflow inbox
    • CQ Admin in fullscreen portlet
    • Multi language support
    • (Personalized) JCR-driven content in portlets like collaboration tools, asset mgmt etc.




    Posted by Michael Marth APR 11, 2008

    Posted in crx, crx quickstart, screencast and tutorial Comments 11

    In the second screencast about CRX Quickstart I show how to create a web site like TheServerSide.com in 15 minutes(*). This is achieved in a Data First-like approach: no schemas or the like have to be set up to get up and running. Since the JCR compliant repository underneath has functionality like search, versioning, access control, etc built right in the software created in this demo is not a throw-away prototype, but can evolve into production.

    (*) The first screencast is here - you might find it beneficial to watch it first if you want to follow the technical details of this screencast.

    Update: for doing the examples yourself with current versions of Sling or CRX Quickstart please see the errata before.

    Posted by Michael Marth APR 10, 2008

    Posted in crx, crx quickstart, screencast and tutorial Comments 9

    In the next days we will release CRX Quickstart. CRX Quickstart bundles CRX and Apache Sling into one installer. This allows you to get going very quickly with JCR-backed web development. In this 15min screencast I present first steps with CRX Quickstart. The code I use is attached to this post.

    Update: for doing the examples yourself with current versions of Sling or CRX Quickstart please see the errata before.

    * firststeps.zip
    firststeps.zip
    * firststeps1.wmv
    firststeps1.wmv

    Posted by Michael Marth APR 02, 2008

    Posted in dynamic languages, jcr and link of the day Add comment

    The link of the day (a bit belated due to my holidays): blogger Chrigel is getting busy in exploring JCR and Groovy/Grails, see here and here. I completely agree with him that the combination of JCR's dynamic nature with a dynamic language on the JVM has tremendous potential. Looking forward to see more of this.

    Posted by Michael Marth APR 02, 2008

    Posted in announcements, day and jackrabbit Add comment

    I mentioned a couple of days ago that there will be a JCR community gathering as a sidetrack of ApacheCon EU in Amsterdam. By now, the list of participants and talks is up on this wiki page. Promises to be an interesting meeting (unfortunately, I will not be able to make it).

    Posted by Michael Marth APR 02, 2008

    Posted in rest and sling Comments 3

    Matt Raible of AppFuse fame has hosted a very entertaining session at the TheServerSide Symposium called "Java Web Framework Smackdown" where proponents of different Java Frameworks took jabs at each other. There were participants for the usual suspects, i.e. JSF, Struts, Rife, GWT, Spring MVC and even Rails. It was quite funny to watch the discussion, but one thing annoyed me: the title of the podium should not have been Web Framework Smackdown, because the presented frameworks are not web frameworks. I would rather call them "application frameworks" because I believe that the term "web framework" should be restricted to frameworks that actually respect and support the way the web is constructed. There are at least two points where the frameworks mentioned above do not do this (as far as I know):

    URLs matter

    In a RESTful architecture the URLs of a resource should not depend on the technology that generated the output stream. I think it should look exactly as if the generated, say, HTML was actually a static file on a web server. Yet a typical URL looks rather like this:

    /detail.jsp?id=123

    This URL explicitly depends on the technology that generates the output. So if the technology needs to be changed the URL is likely to change (unless effort is spent on doing some sort of mapping). This is really uncool in the sense of Tim Berners Lees quote "cool URIs don't change". Often one can also find data base keys in URLs. If the keys change, the url will need to change as well. Last, if the returned data is html the the URL should reflect this. So a good web-like URL would look like this:

    /detail/123.html

    or even better

    /detail/myproduct.html

    I know that some of the above mentioned frameworks allow for customization of the URLs which can fix some of these problems in some cases. But one should not have to.

    State

    In a RESTful architecture state should be kept on the client and no state should be kept on the server. Again, think of the web server with static files. However, a Java application framework usually keeps state. In fact, the first thing your browser will see when you point him to a Java framework-based web application is the session cookie that the application framework sends back.

    In the case of JSF it is even considered to be a main feature that the components are stateful. While I do think that this can come in handy in some cases it is simply not web-like. HTTP is stateless. A true web framework should not hide or try to cirumvene this basic property. Yet, the application frameworks above all do just that.

    Oh, there is one more thing: Apache Sling is a web framework.

    Posted by Peter Klassen APR 02, 2008

    Posted in cms and communique Comment 1

    The version 4.2.1 of Day's Communiqué WCM is a patch release and includes 59 fixes. Significant bug fixes relate to recommended security updates, stability and performance improvements and fixes for the SAP Enterprise Portal Integration. Enhancements include the update of the FCK-Editor to version 2.4.3 and capabilities for a configuration of the page caching.

    Therefore the Advanced Enterprise Content Management System Day Communiqué has reached the next level with increased power, stability, performance and usability.

    The next Communiqué version 4.3 is planned to be available by the end of June 08 and will comprise new features and enhancements such as a Faceted Search, an extended Multi Site Manager and much more.