UX-Bridge - Whitepaper

e-Spirit AG

FirstSpirit Version 5.x

2017-01-17
Table of Contents

1. Introduction and vision

1.1. Websites and user experience

The requirements for modern websites have grown rapidly in recent years. This dynamic is increasingly related to the functionality of the website, which is more often being realized as an interactive communications medium with customers or prospects, as well as to the optimization of the editorial processes.

The requirements with regard to control of this customer communication are becoming more demanding, because consumer expectations are at a very high level. The demanding customer expects an excellent user experience. This term encompasses a multitude of aspects such as good usability, a target group-specific message and delivery of information at the right point in time in the correct granularity. In addition, the performance of a website is gaining in importance, in user acceptance as well as in aspects such as search engine ranking.

1.2. Hybrid architecture

In order to meet the increasingly stringent requirements, an adequate technical solution on the part of the Content Management System (CMS) is necessary. The wide spectrum of user experience requirements makes an unusually flexible architecture of the CMS essential. This particularly applies to aspects that represent the classic oppositional goals, such as:

  • High dynamics of the content versus performant delivery of the website
  • Stable system architecture versus integration of many different tools

In order to offer an optimum solution for the respective customer despite these trade-offs, FirstSpirit provides a particularly adaptable architecture, called hybrid architecture.

The hybrid architecture of FirstSpirit makes it very easy, especially in integration-heavy scenarios, to establish a solution that fits exactly and which takes into account the specific properties and requirements of the website. Experience has shown that a "one-size-fits-all" architecture works only in very simple use cases. As the number and complexity of websites increases, however, the variety of third-party systems to be integrated also increases. Precisely in larger companies, this is a feature that is encountered frequently, because alongside the CMS component, additional systems such as e-commerce shops, enterprise portals, but also self-developed web applications are prescribed and are to be integrated. In such cases, the hybrid architecture of FirstSpirit enables a delicate balance between performance, stability, and maintainability. Most importantly, this balance is customized to the project.

With its hybrid architecture, FirstSpirit follows the rule of:

Providing as much dynamics as necessary; pre-generating as much content as possible.

We understand a hybrid CMS to be a content management system which gives every customer the freedom to choose which elements of a website are fully dynamic and which elements are delivered already pre-generated.

Technically, the two variants mean:

  • Fully dynamic: At the time the user accesses a website (request time), the editorial content is read out and put together live from one or more content repositories.
  • Pre-generated: The editorial content is already physically contained in a website (for example, an HTML file) and can be delivered directly to the user.

A particularity of FirstSpirit’s hybrid approach lies in the fact that the decision in favor of one variant or another can be established in a fine-grained manner for each element of an individual page. Concrete examples for this type of architecture are explained in chapter Examples for operational scenarios.

1.3. UX-Bridge: Connecting Content and user experience

With the trend toward more interactive websites, dynamic access to editorial content has a steadily increasing importance. Wherever pre-generation of content is not possible, the CMS content has to be accessed dynamically. Here, "dynamic" means that the content can change for each website user and at any point in time. Any information that is on the website longer than 1 to 2 minutes and is identical for all users (for example, an article in a news portal) is not considered dynamic here, rather as potentially pre-generated. Nevertheless, the dynamic scenarios are increasing, as personalized content delivery can make an important contribution to the user experience.

With the UX-Bridge module, FirstSpirit offers an infrastructure for the requirement of a dynamic content delivery platform. Consequently, the module expands the hybrid approach by adding a standard infrastructure for dynamic content delivery. As a rule of thumb for the two hybrid architecture variants, we can stipulate that:

  • Pre-generated content delivery of editorial content:
    → FirstSpirit Standard Deployment
  • Fully dynamic content delivery of editorial content:
    → UX-Bridge

It is important to note that these decisions are not global for the entire website, but can be made individually for every type of content element (see examples in chapter Examples for operational scenarios).

When using UX-Bridge, it must be decided per project and per (fine-grained) use case whether the dynamization is functionally and technically necessary or logical (see the above discussion of the trade-off between dynamics and performance). Based on this decision, intelligent and use case-optimized solutions can be implemented very easily.

1.4. Connection to the customer through interaction

Pure content delivery is insufficient to enable true interaction with the users of a website, even if it is personalized and done in a context-oriented manner. Rather, there are a multitude of use cases where information from the website has to flow back in the direction of content creation / CMS. Examples of use cases for this kind of return channel include user-generated content (UGC) or statistical data with regard to user behavior, which can be reused in a second step to optimize content delivery.

With the aid of UX-Bridge, you can store UGC content and read it back out via a standard path. At the same time, UX-Bridge can be used to allow certain information to flow back directly into the editing system from the website (for example, how many comments an article has received) in order to further process them there appropriately, such as for ranking lists.

1.5. Mobile First

The use of mobile end devices to display (web) content has been increasing exponentially for several years. It has now almost become a standard requirement to support a mobile presentation channel for smartphones or tablet PCs alongside a "normal" website. The "Mobile First" approach indeed goes a step further, and recommends that the mobile variant of a website be developed even before the conventional variant. The reasons are that, in the mobile channel, you have to restrict the scope and focus significantly more on the important points, in other words, the content that is relevant to the customer. Furthermore, alongside some technical limitations on mobile devices (for example, screen size), there are also advanced properties such as location tracking via GPS, gesture-based control, changing aspect ratios between portrait and landscape formats or offline capability. These have to be taken into account as soon as the initial design of a website, because they are very difficult to add later without a complete redesign.

By strictly separating content and layout, FirstSpirit makes it very easy to create content fragments that conform to mobile standards such as XML or HTML fragments.

UX-Bridge supplements this approach by adding flexible content delivery infrastructure, which optimally supports the requirements of displaying content for mobile devices. A specific example scenario is described in chapter Mobile news portal.

1.6. New requirements: big data, NoSQL, realtime analytics

Modern websites place ever higher requirements on the underlying technical infrastructure.

The quantities of data to be managed are increasing by leaps and bounds because, alongside classic editorial content, increasing amounts of user-generated content (UGC) and statistical data from the website users' behavior has to be managed and evaluated. Saving and managing such large quantities of data is also associated with the term "big data".

The increasing quantity of data is accompanied by a diversification of data types at the same time. Websites strongly driven by editorial content frequently consist of unstructured data, while website data from backend systems tends to be strongly structured (e.g. product information). User-generated content, such as comments or evaluations, is usually structured very simply and flat. Dependencies or relationships (who viewed what, who knows whom, etc.) reflect an additional type of user data. This "social graph" is a particularly important source of information for user interaction in online communities. An additional use case for relationships between content elements is the so-called "semantic web". Contents are placed in relation to each other there by explicitly modeling connections, such as for improved search options. For this reason, new types of data storage will play an ever-greater role in the future. These include NoSQL or graph databases.

Along with saving editorial and user-specific data, evaluating this data is becoming more and more important. The trend for data analysis is trending increasingly towards realtime reporting. Increasingly, methods from data warehousing and business intelligence are being used to arrive at the relevant analysis.

The mentioned constraints must be taken into account when drafting future-compatible architecture for a website:

  • Constantly increasing data quantities
  • Managing very different types of data
  • Increasing requirements for evaluating data (reporting).

It is worth noting that classic content management repositories were not designed for these extensive requirements at all. From the trade-offs of the requirements, it is apparent that a "one size fits all" approach for the persistence of data is not feasible over the long-term (see chapter Hybrid architecture).

FirstSpirit UX-Bridge therefore follows a new approach: The UX-Bridge architecture enables a flexible selection of data storage (persistence) for dynamic access, depending on the functional and technical requirements (see chapter Polyglot persistence).

1.7. Cloud-ready solution

UX-Bridge was designed from the beginning so that the component can readily be used in the cloud without issue. Aspects such as

  • Scaling and performance
  • Failsafe reliability/failover
  • Operating costs and total cost of ownership (TCO)

are good indicators for operating UX-Bridge in a cloud infrastructure such as Amazon. The same is also true for operating the complete website, and of course, for the FirstSpirit editing system as well. Like all architecture variants, this is an optional possibility which has to be checked for suitability in the respective customer and project situation.

1.8. Content integration platform

Alongside dynamic delivery of editorial content to the website, transferring and forwarding content to third-party applications is an important implementation scenario for UX-Bridge.

Examples of this use case include:

  • Transferring content to a self-developed web application (such as a product configuration or a branch search feature)
  • Transferring content to Cloud/SaaS applications that are intended to be integrated into the website and work on / with editorial content (such as an external recommendation engine or a search engine)

While the FirstSpirit editing system functions as a content-integration platform for the backend, UX-Bridge takes on this role on the live website.

2. Architecture description

UX-Bridge is an extension of the classic, pre-generated FirstSpirit architecture. In contrast to a "fully dynamic CMS", FirstSpirit assumes that the content is compiled in the editing system (backend) and (in many cases) is provided with a suitable target layout as part of what is termed "generation". The results are then, finished HTML pages, for example. Then the generated files are transferred (deployed) to the live system, such as a web or application server. FirstSpirit serves as the content integration layer for editorial content and various connected backend systems (see figure FirstSpirit architecture).

FirstSpirit architecture
Figure 1. FirstSpirit architecture


2.1. Architecture overview of UX-Bridge

As part of the hybrid architecture, UX-Bridge expands FirstSpirit by adding dynamic content delivery using a standard medium. Other (UX-Bridge-free) alternatives to dynamic content delivery are, incidentally, also expressly possible. First, however, a review should be carried out to determine whether or not a standard-based approach such as UX-Bridge would be more beneficial.

Unlike the usual scenario, in the UX-Bridge architecture, those content elements that are to be read out dynamically via a web application are not stored on the web server as finished (HTML) files. Instead, what is called a live repository takes the relevant data from FirstSpirit and forwards it to the dynamic web applications (see figure Pre-generation in combination with UX-Bridge).

Pre-generation in combination with UX-Bridge
Figure 2. Pre-generation in combination with UX-Bridge


It is important that both the approaches of pre-generated files (left side of the graphic) and live repository (right side of the graphic) are usually used in combination with each other (see figure Pre-generation and dynamics).

In this way, in a news portal, the normal press release can be pre-generated entirely statically (as a finished HTML fragment), while on the same page, a Top Rating Widget in the sidebar shows the press releases that have been rated the best "live" (bordered in blue in the illustration).

The hybrid architecture of FirstSpirit enables any desired mixture of such pre-generated and completely dynamic content.

Pre-generation and dynamics
Figure 3. Pre-generation and dynamics


2.1.1. Update content

To stay with the news scenario described above, then the website will be updated via the following steps:

  1. An editor writes a new press release, which is then released via a workflow.
  2. The last workflow step consists of the deployment of the press release, which can be further subdivided:

    1. The press release detail page is completely pre-generated (as static HTML) and then transferred to the web server. The same is true for the news overview page, on which the new notification should appear as the first message.
    2. The data relevant for dynamic display of the press release (here, header for the news item) is generated by FirstSpirit and transferred directly to the live repository without generating a file. The data format can be any one desired, while the reference implementation uses XML, which can contain HTML fragments.

2.1.2. Output content

After updating the content, a website user calls up the press overview page, which contains the latest message as the first link. Clicking on this link opens the detail page just updated (see figure Pre-generation and dynamics). To the right, in the sidebar of the page, is a dynamic WebApp, which takes up contact to the live repository at the time of the request and reads out and shows the Top News.

The architecture does not prescribe the technical mechanisms (for example, via which web framework) with which the WebApp reads out its content from the live repository. Here, any fitting frameworks and protocols can be used.

2.1.3. UX-Bridge architecture in detail

Now that the mechanism of the content update with UX-Bridge has been outlined, this chapter will explain the technical details of the module more closely (see figure UX-Bridge in detail).

On the live side (the presentation layer), UX-Bridge consists of three components:

UX-Bus (or Content-Bus)

UX-Bus forms the central infrastructure component in order to distribute content from FirstSpirit into one or more live repositories. The reference implementation of UX-Bus is technically based on ActiveMQ (see http://activemq.apache.org/). At the same time, UX-Bus can also be used to provide third-party systems with relevant FirstSpirit content (for example, a search index or a recommendation engine). A third use for the UX-Bus is the construction of a back channel from the website in the direction of the FirstSpirit backend (see chapter Connection to the customer through interaction).

UX-Bus forms the central integration component on the live website (see chapter Content integration platform), with which FirstSpirit can interact with the repositories and WebApps, but also with which the WebApps can interact with each other. With the aid of UX-Bus, all participating components can exchange data and events.

Technically, UX-Bus is based on Message Oriented Middleware (MOM). In this way, the UX-Bridge components are only loosely coupled to one another. Simultaneously, scalability is guaranteed through asynchronous communication and the use of queues. To do so, the UX-Bus reference implementation uses ActiveMQ (see http://activemq.apache.org) as a message broker and Apache Camel (http://camel.apache.org/) for the routing and conversion of the messages.

UX-Bridge in detail
Figure 4. UX-Bridge in detail


Live repository

The live repository is a data storage component which is filled by FirstSpirit and read out by web applications. Here, an important paradigm of the UX-Bridge architecture is: The type and number of repositories is not prescribed, because different repositories are differently suited based on task type (see chapter Polyglot persistence).

In many cases, it can also make sense to fill the live repository not exclusively from FirstSpirit, rather also from the website. This is, for example, relevant when administrating user-generated content (UGC). In the live repository, FirstSpirit Content (for example, press releases) is linked with UGC (for example, evaluation of the press releases).

Repository Adapter
The repository adapter takes over inserting the FirstSpirit content in the content repository. Simultaneously, the project-specific FirstSpirit data model of a content object (such as an XML construct with the press release) is mapped to the data model in the repository, which is usually determined by the web application (for example, a relational or NoSQL database). Then the repository adapter always has a project-specific part, i.e., a suitable mapping logic has to be implemented for every kind of data.
Choosing the live repository

Choosing the "correct" live repositories is an important architecture decision within the project. There are always two important questions to answer in the planning phase of a project:

  1. What editorial data should/has to be transferred into a live repository?
  2. What kind of repository is optimal for this kind of data and (web) application?

In general, UX-Bridge does not make any firm specifications here, since various criteria have to be considered for the purpose of a delivery infrastructure suitable for the task:

The type of web application and data
What specific type of web application should be used in regards to the data persistence? What does the data model of the application look like, and in what type of persistence is this data model best mapped? Is a static data model suitable, or is dynamic extensibility necessary? For example, is transactionality important, or is the focus on availability?[1]
Performance and scaling requirements
What are the requirements like in the direction of performance and scalability of the repository? Is horizontal scalability important? How relevant is smoothing load peaks? To what extent does the performance have to be elastic and adjustable?
Third-party systems
What additional systems must have access to the data? What type of persistence do the third-party systems work with best?
Tool and framework support
What kind of repository does the web framework you are using work with particularly well? For what do plugins already exist? Are there additional tools (for example, for import/export/reporting) that have to access the repository?
Expertise in the team
What type of persistence are the developers most familiar with? With which system is the best development performance to be expected?

These are all questions that have to be asked before selecting a repository. They should be answered in order to make a decision on this basis.

For an initial overview, we list some common kinds of repositories here:

  • Relational databases (Oracle, MySQL, PostgreSQL, etc.)
  • NoSQL databases (MongoDB, Cassandra, Redis, SimpleDB, DynamoDB, etc.)
  • Index based storage (Lucene, Solr, Elasticsearch, Sphinxsearch, etc.)
Polyglot persistence

With the described selection of a suitable repository for specific use cases, it is entirely possible that even within a project, multiple, different repositories are used in order to implement a solution suitable for the task. This architectural approach is also called the "polyglot persistence" strategy. This term stands for a simple approach:

Select the suitable persistence for the respective use case.

Simultaneous use of different kinds of persistence is expressly permitted here for data, as long as it makes sense technically. For more details on the topic of polyglot persistence, refer to: http://martinfowler.com/articles/nosql-intro.pdf

The UX-Bridge follows precisely this approach, since the technical requirements determine the selection of the specific types of persistence (also refer to chapter Mobile First).

2.2. Examples for operational scenarios

To answer the question of which scenarios it makes sense to use the UX-Bridge in, following are some practical examples. To support viable architectural decisions, close attention is paid in this relation to which aspects are dynamized and which are logically pre-generated. Selection of a suitable repository is also discussed for each use case.

2.2.1. News scenario including User-generated Content (UGC)

Let us reconsider the news scenario from chapter Architecture overview of UX-Bridge. A website has numerous messages that are administered via the FirstSpirit data sources. The website has news overview pages (with the latest 10 news items on the first page) and news detail pages (see figure News scenario). The detail pages have not only the press release (red border), but also a top news widget (blue border), which dynamically depicts the top news based on certain criteria (highest-rated, etc.).