I have been working a lot recently with Adobe CRX and Adobe CQ (previously from Day) as we build the next generation of Adobe’s CEM Platform (“Customer Experience Management”).
Part of my early work was to understand the basic deployment strategy for for Adobe CQ as it exists already used to publish and manage web sites. What better way than by rolling up your sleeves and doing it, which I have now done and encourage all to try.
For anyone already familiar with CQ and CRX you will no doubt be familiar with our “Quick Start”; literally it is a single JAR file that you can double-click, wait for a minute then Voila! you have a complete WCM solution running on your laptop.
But there is more to it in Production, of course. Typically you need to think about both ends of your user base. On the internet facing side, you obviously don’t plan to expose your poor little java process and its Web Listener to the outside world (right?). Also for your internal developers you don’t want everyone hammering away against your live web pages.
This is not just some custom deployment concern left up to the IT department hosting CQ.
On the internet facing side CRX provides a beautifully light weight and easy to set up “Dispatcher” that drops right into your Apache Listener as a Module. It not only lets you filter acceptable URL requests (your internet end users have no business going to the admin UI!) but it actively caches responses so that if the content being requested has not changed, your request does not need to go back through the application stack.
On the internal facing side for web publishing, CQ lets you set up an “Author” instance where you modify and stage web sites and their dependent content. Then you can have it pushed out to a your “Publish” instance, which is fronted by the Apache Listener with the Dispatcher. There are also many controls over how & when something gets published, such as kicking off an internal approval workflow. When the Author is ready just hit “Activate” on your web content (typically a tree) and then it gets synchronized with your Publish Instance. Note that both instances can be separated by a firewall such that the Author runs in your intranet, while the Publish instance lives in the DMZ
Then there is Clustering, but that’s for another day..
Here is a diagram to give you an idea for how this works (click to view in detail)
There is of course a wealth of information on line at Web Content Management
But since I set this up today and was so pleased with how well it all worked, I just thought I would share my experience. Updating a web page from an Author instance, activating it for Publish, then seeing it render through my Apache Listener was a delight to get working. There’s more to this puppy than a Quick Start JAR file 🙂