Alterian Content Manager (ACM) uses a hub-and-spoke deployment model. A single, central staging or editorial server repository holds all content at all stages of its workflow. Content and site development teams work against this server, usually located on the company network.
Content is delivered to the end consumer from one or more live servers, which connect to read-only slave content repositories. A module on the staging server (the Distribution Server) ensures that content is replicated from the staging to the slave repositories. By default, it will replicate all content in near-real-time to all connected slaves.
The Distribution Server can also be configured to only replicate particular types of content, or at particular statuses, or at certain times of the day - this means that only content that is published and available to the public is pushed through the firewall to the live servers or perhaps a company global intranet requires a server in each region, with some content in common supplemented by specific local content.
The diagram shows an example deployment of ACM, an infrastructure layer consisting of caching, load balancing, a live environment (in this case showing two live servers sharing the load) and a staging server, behind the firewall.
Caching
ACM builds on considerable experience in implementing high-performance systems to dynamically interact with content over the Web. Since the earliest days of the Web, caching has been a fundamental part of its infrastructure.
In using a dynamic delivery model and storing its data in a relational database, ACM offers tremendous control over an organization's content assets and the way they are presented. Intelligent caching ensures that documents are delivered in the timeliest manner, minimizing the use of more expensive network and server resources.
Document caching
The first layer of caching in ACM provides caching of whole HTML pages, images and other complete documents.
In response to a request for an item of content, the display template retrieves the content elements needed. Using the appropriate presentation, the content is rendered into the completed document to be sent back to the browser. Alternatively, for multimedia items, the binary portion of the item is retrieved from the database and sent as is.
A caching proxy is placed in front of this process to satisfy requests for those documents that do not change on every request, without having to re-render the document every time. Such a proxy is often termed an accelerator cache or reverse proxy.
As well as reducing the load on ACM and the database, the use of the proxy has other advantages. When a page is requested it can be returned to the proxy at the speed with which it can be rendered. The proxy can then return it to the browser at the speed of the browser's connection, which could be limited by a slow connection. This avoids tying up ACM server resources in servicing slow clients. A proxy also provides an additional layer of protection and security against the wider Internet, especially when used in conjunction with an intermediate firewall.
By opting for the open solution of the HTTP protocol, customers can use a caching proxy from an independent vendor, using one that best suits their needs and fits in with their existing infrastructure.
Standard headers in HTTP control how individual documents are cached. ACM uses facilities in HTTP/1.1 to enable you to separately control the cache expiry times for the accelerator cache in front of ACM and the private cache in each browser. These times can be set separately for each type of content or template.
Delivery cache
ACM provides application level delivery caches in both the Java and ASP.NET delivery environments. The replicated Java delivery cache utilises the proven JBoss Cache engine to provide enterprise-grade data scalability.
Component caching
Developers of both JSP/Java and ASP.NET delivery templates have tools and techniques available that enable caching components (or in ASP.NET - fragments) of a page, enabling only the very dynamic parts of the page to require refreshing from the ACM server.
Object caching
ACM also uses in-memory caches of objects in the Application Engine, reducing the requirement to go to the database every time and marshal objects from their relational form. Expiry times and cache size can be set independently for individual caches for each class of object. This provides further support for the fast delivery of personalized documents.