Unlike traditional CMS platforms, like web content management systems—which are tightly bound to a particular presentation technology (e.g., .NET, Java, Rails, etc.) and target channel (e.g., web, mobile, e-commerce, etc.)—headless CMS platforms free themselves from prescribing a specific target presentation model.
A headless CMS, often known as an API-first, focus on the freedom from any specific presentation technology or channel. This approach enables the CMS to live up to the promise of managing content in place and publishing anywhere. Adobe Experience Manager supports a headless approach, freeing it from being bound to its historical Java-based web development.
With Adobe Experience Manager version 6.3, Adobe has fully delivered its content-as-a-service (CaaS) implementation using its web services layer.This approach uses the familiar Content Fragments that allow users to create channel-neutral content with variations, which are fully independent of any notion of pages.
In today’s competitive world, organizations are looking to adapt quickly to market changes, while providing a unified, engaging experience to customers across various channels such as web, mobile, business applications, and email. Adobe Experience Manager, now with its CaaS abilities, provides organizations a modern content management foundation to build upon.
With this different approach to content management, in what common logical application layers does Adobe Experience Manager play? Let us quickly review these layers.
Long Release Cycles
A common challenge for organizations that publish content for internally and public-facing applications is having the publishing cadence limited to the application release cycles. Applications, like an e-commerce platform, may follow a two-week release cycle based on the organization’s sprint duration. With content releases tied to the software release, a marketer depends upon the timing of the technical team.
By separating content from the application or presentation tiers, and accessing it on-demand from within applications, the marketers can update and publish content without dependencies upon the development team’s cadence.
It is usual to find some overlap of content consumption across business applications. As a best practice, content is managed in a single location, but is then consumed by or published to a distributed set of applications. To avoid duplication of content and to allow efficient content governance, a company needs to have a central repository where content is created, managed, and from which it is published.
Messaging and brand inconsistencies emerge when many disparate applications within the same organization, built at different times, share common but varied content.These inconsistencies, created by managing content locally within an application, rather than within a common repository, vary sufficiently to impact the messaging and brand experience for the organization.
Let us explore an architecture that eliminates the previous challenges. In the following reference architecture that uses Adobe Experience Manager in a headless manner, we provide a perspective of how to create a robust, highly scalable content delivery solution, while continuing to leverage AEM’s mature, easy-to-use content creation and management environment—the challenge for many CMS platforms is making access to this content through applications just as easy.
All content within AEM is accessible through the Content Service as an API endpoint. Requests made of these APIs make the content available as JSON responses for developers to consume as they need.
Content created is exposed as JSON response through the CaaS feature in AEM to the web services layer. The web services layer is built on Spring Boot outside the AEM platform to ensure that the content/data messaging can be processed, business logic can be implemented, and the response can be cached. The separation of this layer from AEM also ensures a long-term stable web services layer, agnostic of changes in the underlying CMS.
This pluggable architecture makes it possible for the web services layer to continue relaying services seamlessly to several business applications, even if the underlying CMS is replaced with a different one. The web services layer uses Amazon S3 to serialize the cached response. In the event of a crash, the cache stored in the JVM (Java Virtual Machine) or memory gets wiped out. In such cases, the cache can be reinstated by deserializing from Amazon S3.
Alternatively, we can use packaged caching software like Redis. Redis provides Java APIs, called Jedis, to manipulate its cache, which is like Amazon S3 APIs. The web services layer is fronted with Apigee and uses OAuth2 protocol for the security of web services APIs. The business applications pull the content via Apigee. The architecture diagram below shows the process flow.
When new content is created or when existing content is modified in AEM and published, it makes a call to an endpoint in the web services layer, signaling it to clear the cache corresponding to the item published. This ensures that stale content is not shown on business applications.
Adobe Experience Manager
Web Services Layer
Utilizing the above-prescribed robust, integrated software solution, a company can improve its business operations dramatically. Here is how.
Shorter Release Cycles Lead to a Faster Time-to-Market
The use of the AEM platform allows for a very swift content creation-to-publishing pipeline that reduces the time-to-market to mere hours from days or weeks. An efficient content governance model, streamlined deployments, automated workflows, and scheduled publishing allows for quick launches of new products and helps the company stay ahead in the competition.
Central Repository of Content for Consistent Branding
With features like CaaS, content fragment variation for channels and language copy for multiple languages is possible, which can help a company expand the business across geographies and channels rapidly. The dedicated caching mechanism results in impressive page load speed for a company’s business applications.
Standardize Content Structure to Make Quick Changes
Using CaaS features like Content Fragments, the existing business applications can continue to use their respective technologies like React, Angular, etc., and yet become smart and agile when pushing content changes rapidly. The dedicated web services layer ensures a long-standing, central layer to provision content as service seamlessly even if a company decides to switch to a different CMS later.
To conclude, implementing an integrated solution with AEM CaaS and web services can do wonders in business revenue generation. The ease of using the AEM content management system to author information and a swift publishing mechanism significantly decreases the time-to-market for new products.
Further, provisioning the content via web services eliminates the time and effort otherwise spent on migrating business applications onto the AEM platform. The company gets complete benefits of AEM for content management without incurring high costs while migrating these business applications.
Also, by configuring several applications to consume data from the central AEM repository via a single entry-point in the web services layer, the company can project a more unified brand image across all its business applications.