Page tree
Skip to end of metadata
Go to start of metadata

This page illustrates key Magnolia concepts. Find a description for each diagram on the linked pages.

 

ThumbnailCommentPage

Magnolia uses Jackrabbit clustering to share content between instances. In the diagram, each Magnolia instance uses its own persistent storage for website, dam and config workspaces. But the comments workspace is stored in a clustered database.

Clustering

This diagram shows the building blocks you need to a create a custom content app.

Content app framework

A content repository is designed to store, search and retrieve hierarchical data. The data is in a tree of nodes and properties. Properties may store simple values such as numbers and strings or binary data such as images.

Content storage and structure

Java Content Repository (JCR) is a standard interface for accessing content repositories. It decouples content storage from content management and provides a common API for content reuse across the enterprise and between applications.

Content storage and structure

Data store deployment option 1: Completely separate instances. Each instance has a dedicated database and runs on different physical hardware. This setup is good for zero downtime.

Data store deployment

Data store deployment option 2: Centralized database server. A centralized database server holds the copies of JCR repositories for each instance. But the instances run in separate virtual machines. This setup is performant but not disaster tolerant.

Data store deployment

Data store deployment option 3: Clustered data store. All public instances run in a cluster.

Data store deployment

Magnolia is distributed as two webapps: author and public. Editors work on the author instance publishes content to public instances which serve it to visitors.

Instances

Each public instance can serve content targeted for a specific geographical area. For example, one instance serves visitors from Europe and another visitors from the U.S.

Instances

Place secure and sensitive content on separate instances. This diagram shows a possible placement strategy where a public extranet instance resides on its own instance and has its own URL.

Instances

Magnolia instance configurations start from a standard 3-instance setup and scale up. You can add any number of instances for load balancing and high availability. Public instances can subscribe to specific content such as intranet or extranet.

Instances

Modules are independent and pluggable in the sense that you can add and remove them at will. Your module can have a dependency to Magnolia core, your templating kit, or another module.

Modules

Package your modules and resources in a JAR or ZIP file and deploy to production in a controlled manner. The level of environmental control and testing required depends on your client. Consider segregating development, test and production environments.

Modules

Rendering is the process where templates are merged with content. Rendering generates a stream of HTML that can be displayed in the browser. The rendering filter submits a content node to the rendering engine.

Rendering content

Early execution of components. Sometimes components need to execute model code before page rendering starts. This is necessary for operations such as forwarding and redirecting.

Rendering content

Object hierarchy in a JCR repository. A repository contains workspaces. Each workspace contains nodes under a single root node. A node contains properties which store values (data).

Repositories

Request processing and filter chain. In the Magnolia filter chain, filters are executed one-by-one until a filter decides that it can fulfill the request.

Request processing and filters

Elements that make up the Magnolia template mechanism such as template definition and template script.

Templating

Disaster recovery 
Suggested disaster recovery setup:

  1. Run Magnolia software stack on a virtual machine.
  2. Take a snapshot of the whole stack and store the image in disaster recovery store.
  3. Recover the image from DR.

Benefits:

  • Fast: 15 min for 35 GB snapshot, 5 min for 35 GB recovery
  • Preserves current state. Content, templates and resources are in sync when recovered.
 
  • No labels