Java Garbage Collection

Java does not explicitly specify a memory and remove it in the program code. Some people sets the relevant object to null or use System.gc() method to remove the memory explicitly. the garbage collector finds the unnecessary (garbage) objects and removes them.

These hypotheses are called the weak generational hypothesis. So in order to preserve the strengths of this hypothesis, it is physically divided into two – young generation and old generation – in HotSpot VM.

Young generation: Most of the newly created objects are located here. Since most objects soon become unreachable, many objects are created in the young generation, then disappear. When objects disappear from this area, we say a “minor GC” has occurred.

Old generation: The objects that did not become unreachable and survived from the young generation are copied here. It is generally larger than the young generation. As it is bigger in size, the GC occurs less frequently than in the young generation. When objects disappear from the old generation, we say a “major GC” (or a “full GC“) has occurred.

The permanent generation from the chart above is also called the “method area,” and it stores classes or interned character strings. So, this area is definitely not for objects that survived from the old generation to stay permanently. A GC may occur in this area. The GC that took place here is still counted as a major GC.

---

Composition of the Young Generation

In order to understand GC, let’s learn about the young generation, where the objects are created for the first time. The young generation is divided into 3 spaces.

• One Eden space
• Two Survivor spaces

There are 3 spaces in total, two of which are Survivor spaces. The order of execution process of each space is as below:

1. The majority of newly created objects are located in the Eden space.
2. After one GC in the Eden space, the surviving objects are moved to one of the Survivor spaces.
3. After a GC in the Eden space, the objects are piled up into the Survivor space, where other surviving objects already exist.
4. Once a Survivor space is full, surviving objects are moved to the other Survivor space. Then, the Survivor space that is full will be changed to a state where there is no data at all.
5. The objects that survived these steps that have been repeated a number of times are moved to the old generation.

TYPES OF GC

The old generation basically performs a GC when the data is full. The execution procedure varies by the GC type, so it would be easier to understand if you know different types of GC.

According to JDK 7, there are 5 GC types.

1. Serial GC
2. Parallel GC
3. Parallel Old GC (Parallel Compacting GC)
4. Concurrent Mark & Sweep GC  (or “CMS”)
5. Garbage First (G1) GC

Among these, the serial GC must not be used on an operating server. This GC type was created when there was only one CPU core on desktop computers. Using this serial GC will drop the application performance significantly.

Serial GC (-XX:+UseSerialGC)

The GC in the young generation uses the type we explained in the previous paragraph. The GC in the old generation uses an algorithm called “mark-sweep-compact.”

1. The first step of this algorithm is to mark the surviving objects in the old generation.
2. Then, it checks the heap from the front and leaves only the surviving ones behind (sweep).
3. In the last step, it fills up the heap from the front with the objects so that the objects are piled up consecutively, and divides the heap into two parts: one with objects and one without objects (compact).

The serial GC is suitable for a small memory and a small number of CPU cores.

From the picture, you can easily see the difference between the serial GC and parallel GC. While the serial GC uses only one thread to process a GC, the parallel GC uses several threads to process a GC, and therefore, faster. This GC is useful when there is enough memory and a large number of cores. It is also called the “throughput GC.”

Parallel Old GC(-XX:+UseParallelOldGC)

Parallel Old GC was supported since JDK 5 update. Compared to the parallel GC, the only difference is the GC algorithm for the old generation. It goes through three steps: mark – summary – compaction. The summary step identifies the surviving objects separately for the areas that the GC have previously performed, and thus different from the sweep step of the mark-sweep-compact algorithm. It goes through a little more complicated steps.

CMS GC (-XX:+UseConcMarkSweepGC)

As you can see from the picture, the Concurrent Mark-Sweep GC is much more complicated than any other GC types that I have explained so far. The early initial mark step is simple. The surviving objects among the objects the closest to the classloader are searched. So, the pausing time is very short. In the concurrent mark step, the objects referenced by the surviving objects that have just been confirmed are tracked and checked. The difference of this step is that it proceeds while other threads are processed at the same time. In the remarkstep, the objects that were newly added or stopped being referenced in the concurrent mark step are checked. Lastly, in the concurrent sweep step, the garbage collection procedure takes place. The garbage collection is carried out while other threads are still being processed. Since this GC type is performed in this manner, the pausing time for GC is very short. The CMS GC is also called the low latency GC, and is used when the response time from all applications is crucial.

While this GC type has the advantage of short stop-the-world time, it also has the following disadvantages.

• It uses more memory and CPU than other GC types.
• The compaction step is not provided by default.

You need to carefully review before using this type. Also, if the compaction task needs to be carried out because of the many memory fragments, the stop-the-world time can be longer than any other GC types. You need to check how often and how long the compaction task is carried out.

G1 GC

If you want to understand G1 GC, forget everything you know about the young generation and the old generation. As you can see in the picture, one object is allocated to each grid, and then a GC is executed. Then, once one area is full, the objects are allocated to another area, and then a GC is executed. The steps where the data moves from the three spaces of the young generation to the old generation cannot be found in this GC type. This type was created to replace the CMS GC, which has causes a lot of issues and complaints in the long term.

The biggest advantage of the G1 GC is its performance. It is faster than any other GC types that we have discussed so far.

Granite UI, OSGI, Servlet Engine

Granite is Adobe’s open web stack. It forms the technical foundation on which AEM is built.

The Granite engineering platform also provides a foundation UI framework. The major goals of this are to:

• provide granular UI widgets
• implement the UI concepts and illustrate best practices (long lists rendering, lists filtering, object CRUD, CUD wizards…)
• provide an extensible and plug-in based administration UI

These adhere to the requirements:

• respect “mobile first”
• be extensible
• be easy to override

The Granite UI:

• Uses the RESTful architecture of Sling
• Implements component libraries intended for building content-centric web applications
• Provides granular UI widgets
• Provides a default, standardized UI
• Is extensible
• Is designed for both mobile and desktop devices (respects mobile first)
• Can be used in any Granite-based platform/product/project; eg AEM

---

osgi fRAMEWORK

AEM includes an OSGi component framework based on Apache Felix, which implements OSGi Service Platform Release 4.

OSGi is a dynamic software component system for Java. In an OSGi-based system, an application is composed of an assemblage of components, called bundles in OSGi terminology, which can be dynamically installed, started, stopped and uninstalled at runtime, without shutting down and restarting the entire application.

A bundle is a jar file holding Java classes that adhere to the OSGi specification (allowing the classes to connect to and interact with the framework) and a special metadata file (in the jar file’s META-INF subfolder).

Apart from the OSGi framework itself, all other elements of AEM as well as any additional custom applications written on top of the AEM platform are implemented as OSGi bundles.

In a running AEM instance, bundle management is provided through the AEM Web Console at

http://<host&gt;:<port>/system/console/bundles

Servlet Engine

In a quickstart installation, the built-in CQSE servlet engineruns as a bundle within the OSGi framework. In a war file installation servlet handling is delegated to a third-party application server.

AEM includes a built-in servlet engine (CQSE) which runs as a bundle within the OSGi framework when AEM is deployed via the standalone quickstart jar file.

In order to deploy AEM within a third-party application server, the war file package shoud be downloaded and deployed as directed by the application server documentation.

In general, AEM requires an application server that supports Java Servlets API 2.4 or later. For details on which application servers are supported see Servlet Engine and Application Servers. For details on performing the war file deployment see Installing AEM on an Application Server.

Apache Sling

Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content.

Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way.

The embedded Apache Felix OSGi framework and console provide a dynamic runtime environment, where code and content bundles can be loaded, unloaded and reconfigured at runtime.

As the first web framework dedicated to JSR-170 Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications.

Apache Sling in five bullets points

• REST based web framework
• Content-driven, using a JCR content repository
• Powered by OSGi
• Scripting inside, multiple languages (JSP, server-side javascript, Scala, etc.)
• Apache Open Source project

---

AEM is built using Sling, a Web application framework based on REST principles that provides easy development of content-oriented applications. Sling uses a JCR repository, such as Apache Jackrabbit, or in the case of AEM, the CRX Content Repository, as its data store. Sling has been contributed to the Apache Software Foundation – further information can be found at Apache.

Using Sling, the type of content to be rendered is not the first processing consideration. Instead the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering. This provides excellent support for web content authors to build pages which are easily customized to their requirements.

The advantages of this flexibility are apparent in applications with a wide range of different content elements, or when you need pages that can be easily customized. In particular, when implementing a Web Content Management system such as the WCM in the WEM solution.

The following diagram explains Sling script resolution: it shows how to get from HTTP request to content node, from content node to resource type, from resource type to script and what scripting variables are available.

The following diagram explains all the hidden, but powerful, request parameters you can use when dealing with the SlingPostServlet, the default handler for all POST requests that gives you endless options for creating, modifying, deleting, copying and moving nodes in the repository.

• the first target is the resource (JCR node) holding the content
• secondly, the representation, or script, is located from the resource properties in combination with certain parts of the request (e.g. selectors and/or the extension)

Due to the content-centric philosophy, Sling implements a REST-oriented server and thus features a new concept in web application frameworks. The advantages are:

• very RESTful, not just on the surface; resources and representations are correctly modelled inside the server
• removes one or more data models
• previously the following were needed: URL structure, business objects, DB schema;
• this is now reduced to: URL = resource = JCR structure

JCR Content Repository

A JCR is a type of object database tailored to storing, searching, and retrieving hierarchical data. The JCR API grew out of the needs of content management systems, which require storing documents and other binary objects with associated metadata; however, the API is applicable to many additional types of applications. In addition to object storage, the JCR provides: APIs for versioning of data; transactions; observation of changes in data; and import or export of data to XML in a standard way.

All data within AEM is stored in the built-in CRX content repository, which is an implementation of the Java Content Repository Specification (JCR).

All data in AEM is stored in its built-in content repository. The terminology surrounding the repository can sometimes be confusing, so here is a summary:

• The repository built into AEM is called CRX.
• CRX is Adobe’s implemention of the Content Repository Specification for Java Technology 2.0, an official standard published through the Java Community Process as JSR-238 (version 1.0 was known as JSR-170)
• The specification is usually referred to as JCR. JCR designates the type of repository; CRX being one example.
• Another example of a JCR repository is Apache Jackrabbit. Jackrabbit serves as the reference implemention for JCR.
• CRX, while techncially a separate implementation of the specification, is based on the Jackrabbit codebase.

A JCR repository is a specific type of database designed for fine-grained access to hierarchical, unstructured and semi-structure data. It combines features of a traditional relational database with those of a conventional file system.

File system-like features supported by JCR include:

• Hierarchy: Content in a JCR repository can be addressed by path. This is useful when delivering content to the web since most websites are also organized hierarchically.
• Semi-structured content: JCR can store semi-structured documents, like XML, either as opaque files (as a file system would) or as structures ingested directly into the JCR hierarchy.
• Access Control and Locking: JCR can restrict access to different parts of the content hierarchy based on policies or ACLs. It also supports locking of content to prevent conflicts.

Database-like features supported by JCR include:

• Query Access: JCR supports querying with languages such as SQL.
• Structured Content: JCR can enforce constraints on data structures according to a schema.
• Referential Integrity: JCR can enforce referential integrity between content items.
• Transactions: Interactions with a JCR repository can be bracketed in transactions and rolled back when needed.

In addiition, JCR provides the following services that content-centric applications often need, but that neither file systems nor databases typically provide:

• Unstructured Content: JCR can also support arbitrary dynamic data structures without schema constraints.
• Full-Text Search: JCR supports full-text search of content.
• Sort Order: Items within the hierarchy can maintain their ordering, if desired.
• Observation: API clients can register listeners to react to changes made to the repository.
• Versioning: JCR supports an advanced versioning system for repository content.

Adobe Experience Manager

Adobe Experience Manager helps you create, manage, and optimize digital customer experiences across every channel, including web, mobile apps, digital forms, and communities. With the ability to deliver next-generation experiences across both online and in-person interactions, you can increase demand and build lasting brand loyalty.

• Java Platform
  • Java Runtime Environment (JRE 1.6 minimum. JRE 1.7 recommended)
• Granite Platform (runs on JRE)
  • OSGi Framework (encapsulates all subsequent elements)
  • CQSE Servlet Engine (optional external application server)
  • CRX Content Repository
  • Sling Content Delivery
  • Granite UI
• Abobe Experience Manager (runs on Granite platform, within OSGi framework)
  • Individual AEM modules (WCM, DAM, Workflow, etc.)
• Customer Applications (run on AEM)
  • Customer specific applications (websites, etc. also run within OSGi framework)

---

Java Platform

Adobe Experience Manager (AEM) is a Java web application and therefore requires a server-side Java Runtime Environment (JRE). At least JRE 1.6 is required, though JRE 1.7 is recommended.

AEM is available in two forms:

• A quickstart jar file. Simply double-clicking on the jar file will install a standalone instance of AEM complete with a built-in servlet engine. Apart from the JRE itself, no other software infrastructure is required. Once installed the server can be started and stopped either via the desktop GUI or the command line.
• A war file to be deployed in an external application server. In this case, in addition to the the JRE, an application server supporting Java Servlet Specification 2.4 or later is also required.

AEM will run on any OS for which the required JRE is available, this includes Windows, Mac OS X and a variety of Unix systems.

AEM FUNCTIONALITY

The AEM platform is composed of a number of modules. Consult the appropriate section of the documention for more information:

• Web Content Managment
  • Authoring
  • Tagging
  • Content Targeting
  • Multivariate Testing
  • Campaign Management
• Digital Asset Management
• Workflow
• Media Publisher
• Dynamic Media

AEM Instances

While different instances in different environments are all installations of the same AEM software installed in different places in the overall system infrastructure, they differ mainly in the way they are configured. For example, it is that configuration which determines whether a AEM instance behaves as an author instance or a publish instance.

AUTHOR

Author instances are usually located behind the internal firewall. This is the environment where you, and your colleagues, will perform authoring tasks, such as:

• administrate the entire system
• input your content
• configure the layout and design of your content
• activate your content to the publish environment

Content that was activated is packaged and placed in the author environment’s replication queue. The replication process then transports that content to the publish environment.

In order to reverse-replicate data generated in a publish environment back to the author environment, a replication listener in the author environment will poll the publish environment and retrieve such content from the publish environment’s reverse-replication outbox.

PUBLISH

A publish environment is usually located in the Demilitarized Zone (DMZ). This is the environment where visitors will access your website and interact with it; be it public, or within your intranet.

• holds content replicated from the author environment
• makes that content available to the visitors of your website
• stores user data generated by your visitors, such as comments or other form submissions
• may be configured to add such user data to an outbox, for reverse-replication back to the author environment

The publish environment generates your websites content pages dynamically in real-time and the content can be personalized for each individual user.

CLUSTERING AND LOAD BALANCING

To increase availability, and performance, of your Production environment, it is common to combine multiple author and/or publish instances, by either making them available to different groups of users or by load balancing them behind a Dispatcher configuration.

It is also possible to combine multiple instances of the CRX content repository to create a high-availability JCR solution, which can then be integrated with your AEM solution to maximize the protection against hardware and software failure. Such CRX Clusters are supported for various persistence managers. See the CRX Clustering documentation for further information.

Load Balancing

The Dispatcher keeps internal statistics about how fast the web servers are processing documents. Based on this data, the Dispatcher estimates which server will provide the quickest response time when answering a request, and so it assigns the necessary request, and computational time, to that server.

You gain:

Increased response time  

In practice this means that the Dispatcher shares document requests between several web servers. Because each server now has fewer documents to process, you have faster response times. The Dispatcher keeps internal statistics for each document category, so it can estimate the server load and distribute the queries efficiently.

Increased fail-safe coverage

If the Dispatcher does not receive responses from a web server, it will automatically relay requests to the other server(s). Thus, if a server becomes unavailable, the only effect is a slowdown of the site, proportionate to the computational power lost. However, all services will continue.

Increased flexibility

You can also manage different websites on the same static web server.

CACHING, FRYING AND BAKING

Traditionally, the concepts of baking versus frying are an important distinction between different Web Content Management Systems.  In CMS jargon, “baked” refers to the concept of committing data to static files at publish-time, while “fried” refers to the concept of processing data for final presentation at request-time.

The dynamic advantage

When generating a response on request from a visitor, a content management server can read content from a repository, take user preferences and appropriate access rights into account, before transforming the content into a document that is tailored to the visitor’s needs and rights. This allows to provide up-to-date content in real-time in a highly flexible way, but can require significant resources, by demanding more processing power or otherwise causing more computation time, slowing down the response time if many visitors use the system.

The static advantage

When serving a visitor pre-generated static pages, the web server can return that response very quickly, as it can usually be taken directly from memory, at worst it is read from the local drive and served without requiring any further processing. Since these static pages are pre-generated only once, the same content will be delivered for each request and any visitor. This process is very simple, and thus extremely efficient, but does not cater for personalization or dynamic content.

Leveraging caching to combine the advantages

In reality, websites often benefit from a mixture of the two approaches. At its core, AEM processes content dynamically, providing primarily the benefits of a “frying” CMS. By combining this dynamic capability with highly customizable caching rules in the Dispatcher, AEM based web applications can additionally leverage most of the benefits of a “baking” CMS.

AEM can also be used to generate entirely static content, that can for example be burned to CD-ROM or deployed through web servers, which are physically separate from the content management environment. A limitation of traditional “baked” content management solutions is that the process of generating the static output can require a lot of time and significant resources. By appropriately configuring the caching characteristics of AEM, it can be possible to significantly reduce the time required for running the “baking” process, allowing for shorter turnaround times and more frequent updates of large statically served websites.

The Dispatcher allows to take full advantage of caching and load balancing to achieve an environment that is efficient, fast and dynamic. It works as part of a static HTML server, such as Apache, with the aim of:

• storing (or “caching”) as much of the site content as is possible, in the form of a static website.
• accessing the layout engine to retrieve dynamic content as and when necessary, but as little as possible.

Which means that:

• static content is handled with exactly the same speed and ease as on a static web server; additionally you can use the administration and security tools available for your static web server(s).
• dynamic content is generated as needed, without slowing the system down any more than absolutely necessary.

The Dispatcher contains mechanisms to generate, and update, static HTML based on the content of the dynamic site. You can specify in detail which documents are stored as static files and which are always generated dynamically.

Generally, the Dispatcher works on the principle of:

• if the cached document is current, the Dispatcher returns that statically cached version of it immediately
• if the cached document is out of date, the Dispatcher retrieves the current version from the appropriate AEM instance, a step which it can further optimize using Load Balancing

This allows you to take full advantage of a static web server, while retaining the capability to process dynamic content as and when necessary.

CMS (Content Management System)

A content management system (CMS) is a computer application that allows publishing, editing and modifying content, organizing, deleting as well as maintenance from a central interface. Such systems of content management provide procedures to manage workflow in a collaborative environment. These procedures can be manual steps or an automated cascade. CMSs have been available since the late 1990s.

CMSs are often used to run websites containing blogs, news, and shopping. Many corporate and marketing websites use CMSs. CMSs typically aim to avoid the need for hand coding, but may support it for specific elements or entire pages.

The function and use of content management systems is to store and organize files, and provide version-controlled access to their data. CMS features vary widely. Simple systems showcase a handful of features, while other releases, notably enterprise systems, offer more complex and powerful functions. Most CMS include Web-based publishing, format management, revision control (version control), indexing, search, and retrieval. The CMS increments the version number when new updates are added to an already-existing file. Some content management systems also support the separation of content and presentation.

A CMS may serve as a central repository containing documents, movies, pictures, phone numbers, scientific data. CMSs can be used for storing, controlling, revising, semantically enriching and publishing documentation..

Distinguishing between the basic concepts of user and content. The content management system (CMS) has two elements:

Content management application (CMA) is the front-end user interface that allows a user, even with limited expertise, to add, modify and remove content from a Web site without the intervention of a Webmaster.
Content delivery application (CDA) compiles that information and updates the Web site.

A content management system (Web CMS) is a bundled or stand-alone application to create, deploy, manage and store content on Web pages. Web content includes text and embedded graphics, photos, video, audio, and code (e.g., for applications) that displays content or interacts with the user. Content Management has many roles in today’s market place and is an important base for any website blogging, articles, news, description of products etc. A Web CMS may catalog and index content, select or assemble content at runtime, or deliver content to specific visitors in a requested way, such as other languages. Web CMSs usually allow client control over HTML-based content, files, documents, and Web hosting plans based on the system depth and the niche it serves.

WCM (Web Content Management)

A web content management system (WCM) is a software system that provides website authoring, collaboration, and administration tools designed to allow users with little knowledge of web programming languages or markup languages to create and manage website content with relative ease. A robust Web Content Management System provides the foundation for collaboration, offering users the ability to manage documents and output for multiple author editing and participation.

Most systems use a content repository or a database to store page content, metadata, and other information assets that might be needed by the system.

A presentation layer (template engine) displays the content to website visitors based on a set of templates, which are sometimes XSLT files.^[2]

Most systems use server side caching to improve performance. This works best when the WCMS is not changed often but visits happen regularly.

Administration is also typically done through browser-based interfaces, but some systems require the use of a fat client.

A WCMS allows non-technical users to make changes to a website with little training. A WCMS typically requires a systems administrator and/or a web developer to set up and add features, but it is primarily a website maintenance tool for non-technical staff.

POPULAR CMS

Some notable examples of CMS:^[12]

• Adobe Experience Manager: Enterprise Content Manager
• WordPress originated as a blogging CMS, but has been adapted into a full-fledged CMS.
• Textpattern is one of the first open source CMS
• Joomla! is a popular content management system
• Drupal is the third^[13] most used CMS and originated before WordPress and Joomla.
• ExpressionEngine is in the top 5 most used CMSs. It is a commercial CMS made by EllisLab.
• MediaWiki powers Wikipedia and related projects, and is one of the most prominent examples of a wiki CMS.
• Magnolia CMS
• Cascade Server is popular among universities  and enterprise scale organizations
• eXo Platform Open Source Social CMS
• Liferay Open Source Portal WCMS
• TWiki Open Source
• Foswiki Open Source

CAPABILITIES

A web content management system is used to control a dynamic collection of web material, including HTML documents, images, and other forms of media.^[3] A CMS facilitates document control, auditing, editing, and timeline management.

Automated templates Create standard output templates (usually HTML and XML) that can be automatically applied to new and existing content, allowing the appearance of all content to be changed from one central place.Access control Some WCMS systems support user groups. User groups allow you to control how registered users interact with the site. A page on the site can be restricted to one or more groups. This means an anonymous user (someone not logged on), or a logged on user who is not a member of the group a page is restricted to, will be denied access to the page.Scalable expansion Available in most modern WCMSs is the ability to expand a single implementation (one installation on one server) across multiple domains, depending on the server’s settings. WCMS sites may be able to create microsites/web portals within a main site as well.Easily editable contentOnce content is separated from the visual presentation of a site, it usually becomes much easier and quicker to edit and manipulate. Most WCMS software includes WYSIWYG editing tools allowing non-technical users to create and edit content.Scalable feature sets Most WCMS software includes plug-ins or modules that can be easily installed to extend an existing site’s functionality.Web standards upgrades Active WCMS software usually receives regular updates that include new feature sets and keep the system up to current web standards.Workflow management workflow is the process of creating cycles of sequential and parallel tasks that must be accomplished in the CMS. For example, one or many content creators can submit a story, but it is not published until the copy editor cleans it up and the editor-in-chief approves it. Collaboration CMS software may act as a collaboration platform allowing content to be retrieved and worked on by one or many authorized users. Changes can be tracked and authorized for publication or ignored reverting to old versions. Other advanced forms of collaboration allow multiple users to modify (or comment) a page at the same time in a collaboration session.DelegationSome CMS software allows for various user groups to have limited privileges over specific content on the website, spreading out the responsibility of content management.^[6]Document managementCMS software may provide a means of collaboratively managing the life cycle of a document from initial creation time, through revisions, publication, archive, and document destruction.Content virtualizationCMS software may provide a means of allowing each user to work within a virtual copy of the entire web site, document set, and/or code base. This enables changes to multiple interdependent resources to be viewed and/or executed in-context prior to submission.Content syndicationCMS software often assists in content distribution by generating RSS and Atom data feeds to other systems. They may also e-mail users when updates are available as part of the workflow process.MultilingualAbility to display content in multiple languages.VersioningLike document management systems, CMS software may allow the process of versioning by which pages are checked in or out of the WCMS, allowing authorized editors to retrieve previous versions and to continue work from a selected point. Versioning is useful for content that changes over time and requires updating, but it may be necessary to go back to or reference a previous copy.

Types

There are three major types of WCMS:

• offline processing,
• online processing,
• hybrid systems.

These terms describe the deployment pattern for the WCMS in terms of when presentation templates are applied to render web pages from structured content.

Offline processing

These systems, sometimes referred to as “static site generators”,^[7] pre-process all content, applying templates before publication to generate web pages. Since pre-processing systems do not require a server to apply the templates at request time, they may also exist purely as design-time tools.

Online processing

These systems apply templates on-demand. HTML may be generated when a user visits the page or it is pulled from a web cache.

Most open source WCMSs have the capability to support add-ons, which provide extended capabilities including forums, blog, wiki, web stores, photo galleries, contact management, etc. These are often called modules, nodes, widgets, add-ons, or extensions. Add-ons may be based on an open-source or paid license model.

Hybrid systems

Some systems combine the offline and online approaches. Some systems write out executable code (e.g., JSP, ASP, PHP, ColdFusion, or Perl pages) rather than just static HTML, so that the CMS itself does not need to be deployed on every web server. Other hybrids operate in either an online or offline mode.

ADVANTAGES

Low cost

Some content management systems are free, such as Drupal, eZ Publish, TYPO3, Joomla, and WordPress. Others may be affordable based on size subscriptions.^[8] Although subscriptions can be expensive, overall the cost of not having to hire full-time developers can lower the total costs. Plus software can be bought based on need for many CMSs.

Easy customization

A universal layout is created, making pages have a similar theme and design without much code. Many CMS tools use a drag and drop AJAX system for their design modes. It makes it easy for beginner users to create custom front-ends.^[9]

Easy to use

CMSs are designed with non-technical people in mind. Simplicity in design of the admin UI allows website content managers and other users to update content without much training in coding or technical aspects of system maintenance.

Workflow management

CMSs provide the facility to control how content is published, when it is published, and who publishes it. Some WCMSs allow administrators to set up rules forworkflow management, guiding content managers through a series of steps required for each of their tasks.

Good For SEO

CMS websites are also good for search engine optimization (SEO). Freshness of content is one factor that helps, as it is believed that some search engines give preference to website with new and updated content than websites with stale and outdated content. Usage of social media plugins help in weaving a community around your blog. RSS feeds which are automatically generated by blogs or CMS websites can increase the number of subscribers and readers to your site. Url rewriting can be implemented easily which produces clean urls without parameters which further help in seo. There are plugins available that specifically help with website SEO.

DISADVANTAGES

Cost of implementations

Larger scale implementations may require training, planning, and certifications. Certain CMSs may require hardware installations. Commitment to the software is required on bigger investments. Commitment to training, developing, and upkeep are all costs that will be incurred for enterprise systems.^[10]

Cost of maintenance

Maintaining CMSs may require license updates, upgrades, and hardware maintenance.

Latency issues

Larger CMSs can experience latency if hardware infrastructure is not up to date, if databases are not being utilized correctly, and if web cache files that have to be reloaded every time data is updated grow large. Load balancing issues may also impair caching files.

Tool mixing

Because the URLs of many CMSs are dynamically generated with internal parameters and reference information, they are often not stable enough for static pages and other web tools, particularly search engines, to rely on them.

Security

CMS’s are often forgotten about when hardware, software, and operating systems are patched for security threats. Due to lack of patching by the user, a hacker can use unpatched CMS software to exploit vulnerabilities to enter an otherwise secure environment. CMS’s should be part of an overall, holistic security patch management program to maintain the highest possible security standards.

---