Merging Day CQ5, Spring, and JPA for a hybrid web application

If you subscribe to the mantra that “everything is content” then you probably can store everything in CQ and never have a need to integrate with other data-oriented systems.   On the other hand, if your organization or client deals with assets such as relational databases, CRMs, or other systems, your job is probably more interesting and you may want to read on.    What we have seen is that there is a growing demand to integrate the power of a full-fledged WCM, such as Day CQ5, with functionality previously found only in traditional transactional-based web applications.  These hybrid applications must render a web page that integrates both author-controlled content and traditional enterprise data, sourced from assets such as Oracle DB, SAP, Salesforce, etc.  They must also be capable of handling business transactions typically done on the web.

I have seen several different approaches to solving this with CQ5.  A common solution follows a “Content as a Service” pattern where a portal or web application is deployed with a traditional web framework to manage the data sources and transactions and CQ is deployed to manage the content.  The traditional web application generally retrieves the content from CQ via Sling and it is responsible for the actual rendering of the content.     This approach makes sense and especially when a transactional web application is already in place, such as an ecommerce package.  That said, it does have some downsides that may disqualify it from working in all cases.

The biggest downside I see with this approach is that it becomes very difficult/expensive for an author to create and maintain content in-context.  This is because the author is creating content in CQ Author and has no idea how the content is actually going to look when it is rendered by the portal or web application responsible for the rendering.   In many cases, this is perfectly acceptable and sometimes preferred; however, sometimes this is not the case and we took a somewhat different approach to provide a seamless integration between CQ content and typical transactional data.

In our case, several things needed to be accomplished.

• Provide authors with 100% in-context authoring capabilities.  The authoring environment had to have access and display data from Oracle and SAP in order for the authors to merge their content and create a seamless page.

• Simple deployment model all within the CQ container.

• Render pages generated from authored content along with data from sources such as SAP, Oracle.

• Support transactions against an Oracle database.

To achieve these requirements, we took the approach of running everything inside CQ’s Felix container itself.  This allowed us to have a simplified deployment model with all code running within Felix.   Now keep in mind that as a web framework, Sling is engineered towards content-centric functionality and is missing some of the other OOTB functionality you’d get with a more traditional web.    So…, we had to fill in some of the missing pieces.

We selected the Spring framework to start off with.  It provided us with both dependency injection as well as transaction management via annotations.   Sling does not really have a validation/message included so we selected OVal for this.  Then, Apache’s BeanUtil library was selected for it’s magic.  We did not want to be coding direct SQL as that seemed like a huge step backwards from JPA.  The JPA implementation took a bit of time to select.  Ultimately, the EclipseLink product was selected for its OSGI friendliness after wrestling with Hibernate bundles.  For session management, we borrowed ideas from other frameworks such as Struts and Grails.

The challenge of course came in getting these standard tools/frameworks deployed within Felix OSGI so that they were accessible and shared by all web sites built within CQ.   After some wrangling by the team, we succeeded.  Our approach allowed us to have a very lightweight jsp layer with all code residing in POJOs that were structured according to domain driven design principals.  With everything built and deployed by a couple Maven projects, any JEE web developer would be comfortable in this environment.  By rendering data and content within the CQ authoring and publish environments seamlessly, we allowed authors to create content completely in-context and mix/match CRX content with data from Oracle and SAP as desired.

Though this approach would probably not be the best solution for every use case, it did prove to be a powerful option by allowing us the capability to write a custom authoring component that rendered from both content while still leveraging the standard Java framework tooling that web developers expect.   All this and we had a simplified deployment model with a single target platform.