Magnolia 5.3 reached end of life on June 30, 2017. This branch is no longer supported, see End-of-life policy.

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

Magnolia is distributed as two web-applications: author and public. Author instance is where editors work. This instance typically resides in a secure location behind a corporate firewall, inaccessible from the Internet. The author instance publishes content to a public instance. A public instance receives the content and serves it to visitors on the Web. The public instance resides in a publicly reachable location. You can have more than one public instance serving the same or different content. In a typical deployment you have at least two public instances but can have more.

Publish–subscribe pattern

Magnolia's author-public instance model follows the publish-subscribe pattern, a software design principle where the author instance acts as a publisher and public instances take on the role of a subscriber. In this pattern, the publisher classifies content so that subscribers can register interest in particular type of content. In Magnolia, editors organize pages into a website tree on the author instance (equivalent of message filtering in the pub-sub pattern). Public instances can subscribe to a particular path on the site, receiving only content they are interested in.

Benefits

Separating author and public instances has benefits:

  • Security: The author instance typically resides behind a firewall ensuring that your content is never lost. Content can be republished when things go wrong on the public site.
  • Loose coupling: The instances are loosely coupled through subscription and operate independently regardless of the performance of the other. They reside on different servers and the authoring process is not disturbed by public server failure. Public instances can be easily decoupled and recoupled.
  • Scalability: A single author instance can connect to multiple public instances. The model fits any infrastructure size and you can upscale and downscale as necessary.  
  • Flexibility: Variations of content can be served to different public instances. This makes for efficient authoring because content can be reused and adapted to specific audiences.

Magnolia's author/public instance model is very similar to the publish-subscribe messaging pattern.

Differences between author and public instances

Author and public instances run identical software. They both have an AdminCentral that you can log into. The differences are configuration and security only.

ConfigurationAuthorPublic
/server/admintruefalse
/modules/ui-admincentral/virtualURIMapping/default/toURINot set.Set.
anonymous roleHas author instance permissionsHas public instance permissions
anonymous system userHas author instance rolesHas public instance roles
SubscribersHas active subscribersHas no subscribers

See also: Changing author to public instance.

What kind of instance do I have?

There are many ways to find out what kind of instance you have:

  • In AdminCentral, go Tools > About Magnolia.
  • Check the /server/admin property in configuration. It is true for author and false for public instance.
  • In Java code, use the isAdmin() method provided by the  ServerConfiguration  class.
  • In a Freemarker template, use the cmsfn.isAuthorInstance() or cmsfn.isPublicInstance() templating functions.

Public instances serving different content

You can manage multiple sites from the same author instance. 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.

Magnolia multisite feature provides granularity for content control on multilanguage and multidomain installations. Administrators have the option to direct editors to the author instance through a specific domain. Editors edit only the part of the content structure that resides at the specified domain. To ensure a consistent browsing experience, URLs are adapted to always reflect the domain. You can also configure multiple domains to access the same instance.

Intranet and extranet

Place secure and sensitive application instances inside a firewall. The diagram below illustrates a possible placement strategy where an extranet public instance resides outside the firewall but an intranet instance is inside.

Planned redundancy and high availability

A distributed instance setup allows you to respond to high availability requirements and sudden increases in traffic. Here are common problem scenarios:

  • Public instance failure. You have two public instances and due to hardware failure one of them is out of operation for a few days. Start a new public instance to replace the broken one.
  • Sudden high load, also known as Slashdot effect. Start new public instances until the traffic subsides.
  • Public instance blackout. All public instances are corrupted, broken or compromised. No instances exist to serve content.

You can address the issues by adding a new public instance to serve the same content, helping the existing instances deal with the load.

Instance configuration examples

Magnolia configurations range from a minimal one-machine setup to a standard three-instance production setup and beyond.

  • Minimal. Author and Public instances exist on the same server. This is the default configuration when you install Magnolia on your computer to try it.
  • Reduced. Author and Public instances exist on separate servers. The two Public instances are on the same server or one of the Public instances resides on the same server as the Author instance.
  • Standard. Public instances exist on separate servers. This configuration enables load balancing. Incoming requests can be directed to one server or another depending on availability.